OPM fue concebido y desarrollado por Dov Dori . Las ideas que sustentan OPM se publicaron por primera vez en 1995. [2] Desde entonces, OPM ha evolucionado y se ha desarrollado.
En 2002, se publicó el primer libro sobre OPM [3] y el 15 de diciembre de 2015, después de seis años de trabajo por parte de ISO TC184/SC5, ISO adoptó OPM como ISO/PAS 19450. [1] Un segundo libro sobre OPM se publicó en 2016. [4]
Desde 2019, la OPM se ha convertido en la base de un programa de certificación profesional en ingeniería de sistemas basada en modelos (MBSE) en EdX. Las clases están disponibles como videos web en Youtube.
Descripción general
La metodología de proceso de objetos (OPM) es un lenguaje y una metodología de modelado conceptual para capturar conocimiento y diseñar sistemas. Basada en una ontología universal mínima de objetos con estado y procesos que los transforman, la OPM se puede utilizar para especificar formalmente la función, la estructura y el comportamiento de sistemas artificiales y naturales en una gran variedad de dominios. Un modelo OPM, que responde a las capacidades cognitivas humanas, representa el sistema en diseño o estudio de forma bimodal tanto en gráficos como en texto para mejorar la representación, la comprensión, la comunicación y el aprendizaje.
En OPM, un objeto es cualquier cosa que existe o no. Los objetos tienen estado , es decir, pueden tener estados, de modo que en cada momento el objeto se encuentra en uno de sus estados o en transición entre estados. Un proceso es algo que transforma un objeto creándolo o consumiéndolo, o bien cambiando su estado.
El OPM es bimodal; se expresa tanto visualmente/gráficamente en diagramas de proceso-objeto (OPD) como verbalmente/textualmente en lenguaje de proceso-objeto (OPL), un conjunto de oraciones generadas automáticamente en un subconjunto del inglés. Un paquete de software patentado llamado OPCAT, para generar OPD y OPL, está disponible gratuitamente. [5]
Historia
El cambio hacia el paradigma orientado a objetos (OO) para los lenguajes de programación informática , que se produjo en los años 1980 y 1990, fue seguido por la idea de que la programación debería ser precedida por un análisis y diseño orientado a objetos de los programas y, de manera más general, de los sistemas que esos programas representan y sirven. Así, a principios de los años 1990, florecieron más de 30 métodos y notaciones de análisis y diseño orientados a objetos, lo que dio lugar a lo que se conoció como la "guerra de los métodos". [6]
— Dov Dori , "Prefacio", Ingeniería de sistemas basada en modelos con OPM y SysML (2017)
se dio cuenta de que, así como el enfoque procedimental del software era inadecuado, también lo era el enfoque OO “puro”, que coloca a los objetos como los únicos ciudadanos de “primera clase”, siendo los “métodos” (o “servicios”) sus procedimientos subordinados de segunda clase.
— Dov Dori , "Prefacio", Ingeniería de sistemas basada en modelos con OPM y SysML (2017)
Dori publicó el primer artículo sobre OPM en 1995. [2]
En 1997, el lenguaje de modelado unificado (UML), creado por el Object Management Group (OMG), se convirtió en el estándar de facto para el diseño de software. UML 1.1 se presentó al OMG en agosto de 1997 y fue adoptado por el OMG en noviembre de 1997.
El primer libro sobre OPM, Metodología Objeto-Proceso: un Paradigma de Sistemas Holísticos , se publicó en 2002, [3] y desde entonces la OPM se ha aplicado en muchos dominios. [7] [8]
En agosto de 2014, la ISO adoptó la OPM como ISO/PAS 19450. [1]
En 2016 se publicó un segundo libro sobre OPM, que también cubre SysML. [4]
Diseño
La metodología objeto-proceso (OPM) es un paradigma de modelado de sistemas que integra dos aspectos inherentes a cualquier sistema: su estructura y su comportamiento. La estructura se representa a través de los objetos y las relaciones estructurales entre ellos, como la agregación-participación (relación todo-parte) y la generalización-especialización (relación "es-un"). El comportamiento se representa a través de los procesos y cómo transforman los objetos: cómo crean o consumen objetos, o cómo cambian los estados de un objeto. [4] : 2
OPM ofrece una manera de modelar sistemas de casi cualquier dominio, ya sea artificial o natural. [4] : x [9]
Modelado
El lenguaje de proceso de objetos (OPD) consta de diagramas de proceso de objetos (OPD) y un conjunto correspondiente de oraciones en un subconjunto del inglés, llamado lenguaje de proceso de objetos (OPL). El OPL se genera automáticamente mediante OPCAT, [5] una herramienta de software que admite el modelado en OPM. [10]
Diagrama de proceso de objetos (OPD)
OPD es el único tipo de diagrama de OPM. Esta singularidad del tipo de diagrama es un importante contribuyente a la simplicidad de OPM, y está en marcado contraste con UML, que tiene 14 tipos de diagramas, y con SysML, que tiene nueve tipos de este tipo. [11] Un OPD describe gráficamente objetos, procesos y vínculos entre ellos. Los vínculos pueden ser estructurales y procedimentales. Los vínculos estructurales conectan objetos con objetos o procesos con procesos, expresando el aspecto estático del sistema: cómo está estructurado el sistema. Los vínculos procedimentales conectan objetos con procesos, expresando el aspecto dinámico del sistema: cómo cambia el sistema con el tiempo. El sistema completo está representado por un conjunto de OPD organizados jerárquicamente, de modo que el OPD raíz, llamado diagrama de sistemas (SD), especifica la vista "a vista de pájaro" del sistema, y los OPD de nivel inferior especifican el sistema en niveles crecientes de detalle. Todos los OPD del conjunto OPD del sistema son "conscientes" entre sí, y cada uno muestra el sistema, o parte de él, con cierto nivel de detalle. El sistema completo se especifica en su totalidad mediante la unión de los detalles (hechos del modelo) que aparecen en todos los OPD.
Lenguaje de proceso de objetos (OPL)
Cada construcción OPD (es decir, dos o más cosas conectadas por uno o más enlaces) se traduce a una oración en OPL, un subconjunto del inglés natural. El poder de OPL reside en el hecho de que es legible por humanos pero también interpretable por computadoras. Estas son las etapas en las que se toman las decisiones de diseño más importantes. La bimodalidad de gráficos y texto de OPM lo hace adecuado para modelar requisitos de manera conjunta por un equipo que involucra tanto al cliente o su experto en el dominio por un lado, y al arquitecto de sistemas, los modeladores y los diseñadores por el otro. [4] : 3
Simulación animada del modelo OPM
Los modelos OPM no son simplemente representaciones gráficas y textuales estáticas del sistema, sino que también son ejecutables. Un modelo OPM correcto construido en OPCAT se puede simular animándolo, expresando visualmente cómo se comporta el sistema a lo largo del tiempo para lograr su función en todos los niveles de detalle. Un modelo OPM incorrecto no se ejecutará completamente e indicará dónde y por qué está bloqueado, actuando efectivamente como un depurador visual.
Desarrollo
En su prólogo al libro de Dori Ingeniería de sistemas basada en modelos con OPM y SysML , Edward F. Crawley dijo:
La semántica OPM se orientó originalmente a la ingeniería de sistemas, ya que puede modelar información, hardware, personas y regulación. Sin embargo, en los últimos años, la OPM comenzó a ser útil también para los investigadores en biología molecular, lo que produjo nuevos hallazgos publicados relacionados con el ciclo de vida del ARNm. Esto es una indicación clara de la universalidad de la ontología de objetos y procesos. [4] : vi [12]
Lo esencial
El OPM tiene dos partes principales: el lenguaje y la metodología. El lenguaje es bimodal, es decir, se expresa de dos maneras complementarias (modalidades): la parte visual, gráfica (un conjunto de uno o más diagramas de proceso-objeto [OPD]) y la parte textual correspondiente (un conjunto de oraciones en lenguaje de proceso-objeto [OPL], que es un subconjunto del inglés).
El OPD de nivel superior es el diagrama del sistema (SD), que proporciona el contexto para la función del sistema. En el caso de los sistemas creados por el hombre, se espera que esta función beneficie a una persona o a un grupo de personas: el beneficiario. La función es el proceso principal en SD, que también contiene los objetos involucrados en este proceso: el beneficiario, el operando (el objeto sobre el que opera el proceso) y, posiblemente, el atributo cuyo valor cambia el proceso.
Los elementos gráficos de OPM se dividen en entidades, expresadas como formas cerradas, y relaciones, expresadas como enlaces que conectan entidades.
Entidades
Las entidades son los componentes básicos de la OPM. Incluyen objetos y procesos, denominados colectivamente cosas, y estados de objetos.
Objeto
Las asociaciones entre objetos constituyen la estructura de objetos del sistema que se está modelando. En el texto OPL, el nombre del objeto debe aparecer en negrita y con mayúsculas en cada palabra.
Estado del objeto
Un estado de objeto es una clasificación de situación particular de un objeto en algún momento durante su vida. En cada momento, el objeto se encuentra en uno de sus estados o en transición entre dos de sus estados, desde su estado de entrada hasta su estado de salida.
Proceso
Un proceso es una expresión del patrón de transformación de los objetos en el sistema. Un proceso no existe de forma aislada; siempre está asociado con uno o más objetos y se produce o sucede con ellos. Un proceso transforma objetos creándolos, consumiéndolos o cambiando su estado. Por lo tanto, los procesos complementan a los objetos al proporcionar el aspecto dinámico y conductual del sistema. En el texto de OPL, el nombre del proceso debe aparecer en negrita y con mayúscula inicial en cada palabra.
Campo de golf
Enlace estructural
Un vínculo estructural define una relación estructural. Una relación estructural debe especificar una asociación que persista en el sistema durante al menos un intervalo de tiempo.
Enlace de procedimiento
Un vínculo procedimental define una relación procedimental. Una relación procedimental debe especificar cómo opera el sistema para lograr su función, designando la activación condicional o dependiente del tiempo de los procesos que transforman los objetos.
Evento y condición
El paradigma Evento-Condición-Acción proporciona la semántica operativa y el flujo de control de OPM. Un evento es un punto en el tiempo en el que se crea un objeto (o parece crearse desde la perspectiva del sistema) o un objeto entra en un estado especificado. En tiempo de ejecución, este proceso desencadenante inicia la evaluación de la condición previa del proceso. Por lo tanto, iniciar la ejecución de un proceso tiene dos requisitos previos: (1) un evento desencadenante y (2) el cumplimiento de una condición previa.
Una vez que el evento desencadena un proceso, el evento deja de existir.
Sintaxis y semántica
Cosas
Los objetos y los procesos son simétricos en muchos aspectos y tienen mucho en común en términos de relaciones, como agregación, generalización y caracterización.
Para aplicar OPM de manera útil, el modelador debe hacer la distinción esencial entre objetos y procesos, como requisito previo para un análisis y diseño de sistemas exitosos. Por defecto, un sustantivo debe identificar un objeto.
Atributos genéricos de cosa
Las cosas de OPM tienen tres atributos genéricos:
Perserverancia
Esencia
Afiliación
Los atributos genéricos de OPM tienen los siguientes valores predeterminados:
El valor predeterminado del atributo genérico Afiliación de una cosa es sistémico.
La esencia del sistema será la esencia primaria del sistema. Al igual que la esencia de las cosas, sus valores son informáticos y físicos. Los sistemas de información, en los que la mayoría de las cosas son informáticas, serán principalmente informáticos, mientras que los sistemas en los que la mayoría de las cosas son físicas serán principalmente físicos.
El valor predeterminado del atributo genérico Esencia de una cosa en un sistema principalmente informático [físico] será informático [físico].
Estados de objeto
Objetos con estado y sin estado
Dov Dori explica en Model-Based Systems Engineering with OPM and SysML que "Un estado de objeto es una situación posible en la que un objeto puede existir. Un estado de objeto tiene significado solo en el contexto del objeto al que pertenece". Un objeto sin estado debe ser un objeto que no tiene ninguna especificación de estados. Un objeto con estado debe ser un objeto para el cual se especifica un conjunto de estados permitidos. En un modelo de tiempo de ejecución, en cualquier momento, cualquier instancia de objeto con estado se encuentra en un estado permitido particular o en transición entre dos estados.
Valores de los atributos
Un atributo es un objeto que caracteriza a una cosa. Un valor de atributo es una especialización de estado en el sentido de que un valor es un estado de un atributo: un objeto tiene un atributo, que es un objeto diferente, al que se le asigna ese valor durante un período de tiempo durante la existencia del objeto que exhibe ese atributo.
Representación del estado del objeto
Un estado se define gráficamente mediante un rectángulo con las esquinas redondeadas y una etiqueta que se coloca dentro del objeto propietario. No puede existir sin un objeto. En el texto de OPL, el nombre del estado debe aparecer en negrita y sin mayúsculas.
Estados inicial, predeterminado y final
Representación del estado inicial, final y predeterminado
Un estado inicial se define gráficamente mediante una representación de estado con un contorno grueso. Un estado final se define gráficamente mediante una representación de estado con un contorno doble. Un estado predeterminado se define gráficamente mediante una representación de estado con una flecha abierta que apunta en diagonal desde la izquierda. Las sentencias OPL correspondientes deben incluir indicadores explícitos para un estado inicial, final o predeterminado.
Campo de golf
Enlaces de procedimiento
Un vínculo procedimental es de tres tipos:
Enlace transformador , que conecta un transformador (un objeto que el proceso transforma) o su estado con un proceso para modelar la transformación de un objeto, es decir, la generación, el consumo o el cambio de estado de ese objeto como resultado de la ejecución del proceso.
Enlace habilitador , que conecta un habilitador (un objeto que habilita la ocurrencia del proceso pero no es transformado por ese proceso) o su estado, a un proceso, que habilita la ocurrencia de ese proceso.
Enlace de control , que es un enlace procedimental (transformador o habilitador) con un modificador de control: la letra e (para evento) o c (para condición), que agrega la semántica de un elemento de control. La letra e significa un evento para activar el proceso vinculado, mientras que la letra c significa una condición para la ejecución del proceso vinculado, o la conexión de dos procesos que denotan invocación o excepción.
Principio de unicidad del vínculo procedimental OPM
Un proceso necesita transformar al menos un objeto. Por lo tanto, un proceso debe estar conectado a través de un enlace de transformación a al menos un objeto o estado de objeto. En cualquier grado particular de abstracción, un objeto o cualquiera de sus estados debe tener exactamente un rol como elemento de modelo con respecto a un proceso al que se vincula: el objeto puede ser un objeto transformado o un habilitador. Además, puede ser un disparador para un evento (si tiene el modificador de control e), o un objeto de condicionamiento (si tiene el modificador de control c), o ambos.
Vínculos procesales especificados por el Estado
Un enlace procedimental especificado por estado es una versión detallada de su contraparte de enlace procedimental en el sentido de que, en lugar de conectar un proceso a un objeto, conecta un proceso a un estado específico de ese objeto.
Transformando enlaces
Los tres tipos de enlaces transformadores son:
Enlace de consumo : Gráficamente, una flecha con la punta cerrada que apunta desde el consumidor al proceso consumidor define el enlace de consumo. Por supuesto, el objeto consumido desaparece tan pronto como el proceso comienza su ejecución. La sintaxis de una sentencia OPL de enlace de consumo es: El procesamiento consume al consumidor.
Enlace de efecto : Un enlace de transformación que especifica que el proceso vinculado afecta al objeto vinculado, que es el afectado, es decir, el proceso causa algún cambio no especificado en el estado del afectado. Gráficamente, una flecha bidireccional con dos puntas de flecha cerradas, una apuntando en cada dirección entre el proceso que afecta y el objeto afectado, definirá el enlace de efecto. La sintaxis de una sentencia OPL de enlace de efecto es: El procesamiento afecta al afectado.
Enlace de resultado : Gráficamente, una flecha con la punta cerrada que apunta desde el proceso de creación hasta el resultado definirá un enlace de resultado. La sintaxis de una sentencia OPL de enlace de resultado es: El procesamiento produce el resultado.
Habilitación de enlaces
Un vínculo habilitador es un vínculo de procedimiento que especifica un habilitador para un proceso: un objeto que debe estar presente para que se produzca ese proceso, pero la existencia y el estado de ese objeto una vez finalizado el proceso son los mismos que antes de que comenzara el proceso. Los dos tipos de vínculos habilitadores son:
Agente y enlace de agente : Un ser humano o un grupo de seres humanos capaces de tomar decisiones inteligentes, que habilitan un proceso al interactuar con el sistema para habilitar o controlar el proceso durante la ejecución. Gráficamente, una línea con un círculo relleno ("piruleta negra") en el extremo terminal que se extiende desde el objeto de agente hasta el proceso que habilita define un enlace de agente. La sintaxis de una sentencia OPL de enlace de agente es: El agente maneja el procesamiento.
Instrumento y vínculo entre instrumentos : Un facilitador inanimado o de otro modo no decisivo de un proceso que no puede comenzar o tener lugar sin la existencia y disponibilidad del instrumento.
Enlaces de transformación especificados por el estado
Enlace de consumo especificado por estado : un enlace de consumo que se origina a partir de un estado particular del objeto consumido, lo que significa que el objeto consumido debe estar en ese estado para que el proceso al que está vinculado pueda consumirlo. Gráficamente, una flecha con la punta cerrada que apunta desde el estado particular del objeto al proceso que consume el objeto define el enlace de consumo especificado por estado.
Enlace de resultado especificado por estado : un enlace de resultado que termina en un estado específico del resultado, lo que significa que el resultado debe estar en ese estado resultante al momento de su construcción. Gráficamente, una flecha con la punta cerrada que apunta desde el proceso al estado del objeto en particular define el enlace de resultado especificado por estado. La sintaxis de la oración OPL es: El proceso produce un objeto de estado calificado.
Enlaces de efectos especificados por el estado :
Enlaces de efectos de entrada y salida: un enlace de entrada es el enlace del estado de entrada del objeto al proceso de transformación, mientras que el enlace de salida es el enlace del proceso de transformación al estado de salida del objeto.
Enlace de efecto especificado de entrada-salida: un par de enlaces de efecto, donde el enlace de entrada se origina en un estado particular del afectado y el enlace de salida se origina en ese proceso y termina en el estado de salida del mismo afectado. Gráficamente, un par de flechas con una punta de flecha cerrada desde el estado de entrada del afectado hasta el proceso que afecta y una flecha similar desde ese proceso hasta el estado del afectado cuando el proceso termina define el enlace de efecto especificado de entrada-salida. La sintaxis de la oración OPL es: El proceso cambia el objeto del estado de entrada al estado de salida.
Enlace de efecto especificado por la entrada: un par de enlaces de efecto, donde el enlace de entrada se origina en un estado particular del afectado y el enlace de salida se origina en ese proceso y termina en el afectado sin especificar un estado particular. Gráficamente, un par de flechas que consisten en una flecha con una punta de flecha cerrada desde un estado particular (el estado de entrada) del afectado hasta el proceso, y una flecha similar desde ese proceso hasta el afectado pero no hasta ninguno de sus estados define el enlace de efecto especificado por la entrada. La oración de sintaxis OPL es: El proceso cambia el objeto desde el estado de entrada.
Enlace de efecto especificado por la salida: un par de enlaces de efecto, donde el enlace de entrada (fuente) se origina en un afectado, y el enlace de salida se origina en el proceso y termina en el estado de salida (destino, resultante) del mismo afectado. Gráficamente, un par de flechas que consisten en una flecha con una punta de flecha cerrada desde el afectado, pero no desde ninguno de sus estados, hasta el proceso que afecta, y una flecha similar desde ese proceso hasta un estado particular de ese afectado (el estado de salida) define el enlace de efecto especificado por la salida.
Enlaces habilitadores especificados por el estado
Se originan en un estado calificado específico y terminan en un proceso, lo que significa que el proceso puede ocurrir si y solo si el objeto existe en el estado desde el que se origina el enlace.
Enlace de agente especificado por estado : Gráficamente, una línea con un círculo relleno ("piruleta negra") en el extremo terminal que se extiende desde el estado de calificación del objeto de agente hasta el proceso que habilita define un enlace de agente especificado por estado. La sintaxis de la oración OPL es: El agente de estado de calificación maneja el procesamiento.
Enlace de instrumento especificado por estado : un enlace de instrumento que se origina a partir de un estado de calificación específico del instrumento. Gráficamente, una línea con un círculo vacío ("piruleta blanca") en el extremo terminal que se extiende desde el estado de calificación del objeto de instrumento hasta el proceso que habilita define un enlace de instrumento especificado por estado. La oración de sintaxis OPL es: El procesamiento requiere un instrumento de estado de calificación.
Control de evento-condición-acción
Conjunto de objetos de preprocesamiento y condición previa del proceso
Para que un proceso OPM comience a ejecutarse una vez que se ha activado, necesita un conjunto de objetos que comprenda uno o más consumos, algunos posiblemente en estados específicos, y/o efectos, denominados colectivamente el conjunto de objetos de preproceso. En la ejecución a nivel de instancia, cada consumo B en el conjunto de objetos de preproceso del proceso P se consumirá y dejará de existir al comienzo del subproceso de nivel más bajo de P que consume B. Cada B afectado (un objeto cuyo estado cambia) en el conjunto de objetos de preproceso del proceso P saldrá de su estado de entrada al comienzo del subproceso de nivel más bajo de P.
Conjunto de objetos de posprocesamiento y poscondición del proceso
Un conjunto de objetos, que comprende uno o más resultados, algunos posiblemente en estados determinados, y/o efectos, denominados colectivamente el conjunto de objetos de post-proceso, resultará de la ejecución de un proceso y de la realización de las transformaciones asociadas con su ejecución. Cada resultado B en el conjunto de objetos de post-proceso del proceso P se creará y comenzará a existir al final del subproceso de nivel más bajo de P que produce B. Cada B afectado en el conjunto de objetos de post-proceso del proceso P entrará en su estado de salida al final del subproceso de nivel más bajo de P.
Enlaces de control
Un vínculo de evento y un vínculo de condición expresan un evento y una condición, respectivamente. Los vínculos de control se producen entre un objeto y un proceso o entre dos procesos.
Enlaces de eventos
La activación de un proceso inicia un intento de ejecución del proceso, pero no garantiza el éxito de este intento. El evento de activación obliga a una evaluación de la condición previa del proceso para determinar su cumplimiento, que, si se cumple y solo si se cumple, permite que la ejecución del proceso continúe y el proceso se active. Independientemente de si se cumple o no la condición previa, el evento se perderá. Si la condición previa no se cumple, la ejecución del proceso no se producirá hasta que otro evento active el proceso y una evaluación de condición previa satisfactoria permita que el proceso se ejecute.
Vínculos de eventos de transformación básicos : un vínculo de evento de consumo es un vínculo entre un objeto y un proceso, que una instancia del objeto activa.
Enlace de evento de consumo: Gráficamente, una flecha con la punta cerrada que apunta desde el objeto al proceso con la letra e minúscula (de evento). La sintaxis de una sentencia OPL de enlace de evento de consumo es: El objeto activa el proceso, que consume el objeto.
Enlace de evento de efecto: Gráficamente, una flecha bidireccional con puntas de flecha cerradas en cada extremo entre el objeto y el proceso con una letra e minúscula (de evento). La sintaxis de una sentencia OPL de enlace de evento de efecto es: El objeto activa el proceso, que afecta al objeto.
Enlaces básicos de eventos habilitadores :
Enlace de evento de agente: un enlace de evento de agente es un enlace de habilitación desde un objeto de agente hasta el proceso que activa y habilita. Gráficamente, una línea con un círculo relleno ("piruleta negra") en el extremo terminal que se extiende desde un objeto de agente hasta el proceso que activa y habilita con una letra e minúscula (de evento). La sintaxis de una sentencia OPL de enlace de evento de agente es: El agente activa y maneja el proceso.
Enlace de evento de instrumento: Gráficamente, una línea con un círculo vacío ("piruleta blanca") en el extremo terminal que se extiende desde el objeto de instrumento hasta el proceso que activa y habilita con una letra e minúscula (de evento). La sintaxis de una sentencia OPL de enlace de evento de instrumento es: El instrumento activa el proceso, que requiere el instrumento.
Enlaces de eventos de transformación especificados por el estado :
Enlace de evento de consumo especificado por estado: un enlace de evento de consumo especificado por estado es un enlace de consumo que se origina en un estado específico de un objeto y finaliza en un proceso, que una instancia del objeto activa. Gráficamente, una flecha con la punta de flecha cerrada que apunta desde el estado del objeto al proceso con la letra e minúscula (de evento). La sintaxis de una sentencia OPL de enlace de evento de consumo especificado por estado es: Un objeto de estado especificado activa un proceso, que consume un objeto.
Enlace de evento de efecto especificado de entrada-salida: Un enlace de evento de efecto especificado de entrada-salida es un enlace de efecto especificado de entrada-salida con el significado adicional de activar el proceso que afecta cuando el objeto ingresa al estado de entrada especificado. Gráficamente, el enlace de efecto especificado de entrada-salida con una letra e minúscula (de evento). La sintaxis de una sentencia OPL de enlace de evento de efecto especificado de entrada-salida es: El objeto de estado de entrada activa el proceso, que cambia el objeto del estado de entrada al estado de salida.
Enlace de evento de efecto especificado por entrada: un enlace de evento de efecto especificado por entrada es un enlace de efecto especificado por entrada con el significado adicional de activar el proceso que afecta cuando el objeto ingresa al estado de entrada especificado. Gráficamente, el enlace de efecto especificado por entrada con una letra e minúscula (para evento). La sintaxis de una sentencia OPL de enlace de evento de efecto especificado por entrada es: El objeto de estado de entrada activa el proceso, que cambia el objeto del estado de entrada.
Enlace de evento de efecto especificado por salida: Un enlace de evento de efecto especificado por salida es un enlace de efecto especificado por salida con el significado adicional de activar el proceso que afecta cuando el objeto entra en existencia. Gráficamente, el enlace de efecto especificado por salida con una letra e minúscula (de evento). La sintaxis de una sentencia OPL de enlace de evento de efecto especificado por salida es: El objeto en cualquier estado activa el proceso, que cambia el objeto al estado de destino
Enlace de evento de agente especificado por estado :
Enlace de evento de agente especificado por estado: un enlace de evento de agente especificado por estado es un enlace de agente especificado por estado con el significado adicional de activar el proceso cuando el agente ingresa al estado especificado. Gráficamente, el enlace de agente especificado por estado se escribe con una letra e minúscula (de evento). La sintaxis de una oración OPL de enlace de evento de agente especificado por estado es: "El agente de estado calificado activa y maneja el procesamiento".
Enlace de evento de instrumento especificado por estado: un enlace de evento de instrumento especificado por estado es un enlace de instrumento especificado por estado con el significado adicional de activar el proceso cuando el instrumento ingresa al estado especificado. Gráficamente, el enlace de instrumento especificado por estado con una letra e minúscula (de evento). La sintaxis de una oración OPL de enlace de evento de instrumento especificado por estado es: "El instrumento de estado calificado activa el procesamiento, que requiere un instrumento de estado calificado".
Enlaces de invocación
Invocación de proceso
Enlace de autoinvocación
Vínculo de invocación implícita : la invocación implícita ocurre cuando finaliza un subproceso dentro del contexto de un proceso ampliado, momento en el cual el subproceso invoca al o los subprocesos inmediatamente inferiores. Gráficamente, no existe un vínculo entre el subproceso que invoca y el invocado; sus alturas relativas dentro del contexto ampliado de su proceso antecesor implican esta semántica.
Enlaces de condición
Un enlace de condición es un enlace de procedimiento entre un objeto de origen o un estado de objeto y un proceso de destino que proporciona un mecanismo de derivación.
Enlace de consumo de condición : un enlace de consumo de condición es un enlace de condición de un objeto a un proceso, lo que significa que si en tiempo de ejecución existe una instancia de objeto, entonces se cumple la condición previa del proceso, el proceso se ejecuta y consume la instancia de objeto. Gráficamente, una flecha con una punta de flecha cerrada que apunta desde el objeto al proceso con la letra c minúscula (de condición) cerca de la punta de flecha indicará un enlace de consumo de condición.
Vínculo de efecto de condición : Sin embargo, si esa instancia de objeto no existe, la evaluación de la condición previa del proceso falla y el control omite el proceso. Gráficamente, una flecha bidireccional con dos puntas de flecha cerradas, una apuntando en cada dirección entre el objeto afectado y el proceso afectado, con la letra c minúscula (de condición) cerca del extremo del proceso de la flecha.
Enlace de agente de condición : Gráficamente, una línea con un círculo relleno ("piruleta negra") en el extremo terminal que se extiende desde un objeto de agente hasta el proceso que habilita, con la letra c minúscula (de condición) cerca del final del proceso. La sintaxis de la oración OPL de enlace de agente de condición es: El agente maneja el proceso si el agente existe, de lo contrario, se omite el proceso .
Enlace de instrumento de condición : Gráficamente, una línea con un círculo vacío ("piruleta blanca") en el extremo terminal, que se extiende desde un objeto de instrumento hasta el proceso que habilita, con la letra c minúscula (de condición) cerca del final del proceso, denotará un enlace de instrumento de condición. La sintaxis de la sentencia OPL de enlace de instrumento de condición será: El proceso ocurre si el instrumento existe, de lo contrario, se omite el proceso .
Enlace de consumo especificado por el estado de la condición : un enlace de consumo especificado por el estado de la condición es un enlace de consumo de condición que se origina a partir de un estado especificado de un objeto y finaliza en un proceso, lo que significa que si existe una instancia de objeto en el estado especificado y se satisface el resto de la condición previa del proceso, entonces el proceso se ejecuta y consume la instancia de objeto. Gráficamente, una flecha con una punta de flecha cerrada que apunta desde el estado de calificación del objeto al proceso con la letra c minúscula (de condición) cerca de la punta de flecha.
Enlace de efecto especificado de entrada-salida de condición : Un enlace de efecto especificado de entrada-salida de condición es un enlace de efecto especificado de entrada-salida con el significado adicional de que si en tiempo de ejecución existe una instancia de objeto y está en el estado de entrada del proceso (y suponiendo que se satisface el resto de la condición previa del proceso), entonces el proceso se ejecuta y afecta a la instancia del objeto. Gráficamente, el enlace de efecto especificado de entrada-salida de condición con la letra c minúscula (de condición) cerca de la punta de flecha de la entrada. La sintaxis de la oración OPL enlace de efecto especificado de entrada-salida de condición es: El proceso ocurre si el objeto es estado de entrada, en cuyo caso el proceso cambia el objeto del estado de entrada al estado de salida, de lo contrario se omite el proceso.
Enlace de efecto especificado por entrada de condición : Un enlace de efecto especificado por entrada de condición es un enlace de efecto especificado por entrada con el significado adicional de que si en tiempo de ejecución existe una instancia de objeto en el estado de entrada especificado y se satisface el resto de la condición previa del proceso, entonces el proceso se ejecuta y afecta a la instancia de objeto cambiando su estado de su estado de entrada a un estado no especificado. Sin embargo, si esa instancia de objeto no existe en el estado de entrada, entonces la evaluación de la condición previa del proceso falla y el control omite el proceso. Gráficamente, el enlace de efecto especificado por entrada de condición con la letra c minúscula (de condición) cerca de la punta de flecha del enlace de entrada. La sintaxis de una oración OPL de enlace de efecto especificado por entrada de condición es: El proceso ocurre si el objeto es el estado de entrada, en cuyo caso el proceso cambia el objeto del estado de entrada, de lo contrario se omite el proceso.
Enlace de efecto especificado de salida de condición : un enlace de efecto especificado de salida de condición es un enlace de efecto especificado de salida con el significado adicional de que si en tiempo de ejecución existe una instancia de objeto y se satisface el resto de la condición previa del proceso, entonces el proceso se ejecuta y afecta la instancia de objeto cambiando su estado al estado de salida especificado. Sin embargo, si esa instancia de objeto no existe, entonces la evaluación de la condición previa del proceso falla y el control omite el proceso. Gráficamente, el enlace de efecto especificado de salida de condición con la letra c minúscula (para condición) cerca de la punta de flecha del enlace de entrada. La sintaxis de la oración OPL de efecto especificado de salida de condición es: El proceso ocurre si existe el objeto , en cuyo caso el proceso cambia el objeto al estado de salida , de lo contrario el proceso se omite.
Enlace de agente especificado por estado de condición : La sintaxis de la oración OPL de enlace de agente especificado por estado de condición es: El agente maneja el proceso si el agente está en estado de calificación ; de lo contrario, se omite el proceso .
Enlace de instrumento especificado por estado de condición
Puede encontrar más información y ejemplos en Ingeniería de sistemas basada en modelos con OPM y SysML , Capítulo 13 "El aspecto del sistema dinámico". [4]
Enlaces estructurales
Los vínculos estructurales especifican relaciones estáticas, independientes del tiempo y duraderas en el sistema. Un vínculo estructural conecta dos o más objetos o dos o más procesos, pero no un objeto y un proceso, excepto en el caso de un vínculo de exhibición-caracterización.
Enlace estructural etiquetado unidireccional
Tiene una semántica definida por el usuario en cuanto a la naturaleza de la relación entre una cosa y otra. Gráficamente, una flecha con la punta abierta. A lo largo del vínculo estructural etiquetado, el modelador debe registrar una etiqueta significativa en forma de frase textual que exprese la naturaleza de la relación estructural entre los objetos (o procesos) conectados y que tenga sentido cuando se coloque en la oración OPL cuya sintaxis sigue.
Enlace estructural unidireccional con etiqueta nula
Un vínculo estructural etiquetado unidireccional sin etiqueta. En este caso, se utiliza la etiqueta unidireccional predeterminada. El modelador tiene la opción de configurar la etiqueta unidireccional predeterminada para un sistema específico o un conjunto de sistemas. Si no se define ninguna etiqueta predeterminada, la etiqueta predeterminada es "se relaciona con".
Enlace estructural etiquetado bidireccional
Cuando las etiquetas en ambas direcciones son significativas y no solo inversas entre sí, pueden registrarse mediante dos etiquetas en cada lado de un único enlace estructural etiquetado bidireccional. La sintaxis del enlace estructural etiquetado resultante son dos oraciones OPL de enlace estructural etiquetado separadas, una para cada dirección. Gráficamente, una línea con puntas de flecha en forma de arpón en lados opuestos en ambos extremos de la línea del enlace.
Enlace estructural recíproco etiquetado
Un enlace estructural etiquetado bidireccional con una etiqueta. En cualquier caso, la reciprocidad indica que la etiqueta de un enlace estructural bidireccional tiene la misma semántica para sus direcciones hacia adelante y hacia atrás. Cuando no aparece ninguna etiqueta, la etiqueta predeterminada será "están relacionados". La sintaxis del enlace estructural etiquetado recíproco con una sola etiqueta será: El objeto de origen y el objeto de destino son etiquetas de reciprocidad. La sintaxis del enlace estructural etiquetado recíproco sin etiqueta es: El objeto de origen y el objeto de destino están relacionados.
Relaciones estructurales fundamentales
Las relaciones estructurales más frecuentes entre las cosas OPM son de particular importancia para especificar y comprender los sistemas. Cada una de las relaciones fundamentales es elaborar o refinar una cosa OPM, la cosa de origen o refinada, en una colección de una o más cosas OPM, la cosa o cosas de destino o refinables.
Vínculo agregación-participación
Un refinado (el todo) agrega uno o más elementos refinables (las partes). Gráficamente, un triángulo negro sólido (relleno) con su vértice conectado por una línea al todo y las partes conectadas por líneas a la base horizontal opuesta denotará el vínculo de relación de agregación-participación.
Enlace exposición-caracterización
Una cosa exhibe, o es caracterizada por, otra cosa. La relación de exhibición-caracterización vincula a un refinado (el expositor) con uno o más refinables, que identificarán características que caracterizan al expositor. Gráficamente, un triángulo negro más pequeño dentro de un triángulo vacío más grande con el vértice de ese triángulo más grande conectado por una línea al expositor y las características conectadas a la base opuesta (horizontal) define el vínculo de la relación de exhibición-caracterización.
Generalización-especialización y herencia
Se trata de relaciones estructurales que permiten abstraer cualquier número de objetos o clases de procesos en superclases y asignar atributos de superclases a clases subordinadas.
Vínculo generalización-especialización
Herencia por especialización
Restricción de especialización mediante atributo discriminante : un subconjunto de los valores posibles de un atributo heredado puede restringir la especialización.
Clasificación-instanciación y ejecución del sistema
Vínculo de clasificación-instanciación : una cosa de origen, que es una clase de objeto o una clase de proceso, se conecta a una o más cosas de destino, que son instancias valoradas del patrón de la cosa de origen, es decir, las características especificadas por el patrón adquieren valores explícitos. Esta relación proporciona al modelador un mecanismo explícito para expresar la relación entre una clase y sus instancias creadas por la provisión de valores de característica. Gráficamente, un pequeño círculo negro dentro de un triángulo más grande que de otro modo estaría vacío con el vértice que se conecta mediante una línea a la cosa de clase y las cosas de instancia que se conectan mediante líneas a la base opuesta define el vínculo de relación de clasificación-instanciación. La sintaxis es: Instancia-cosa es una instancia de Clase-cosa.
Instancias de la clase de objeto y de la clase de proceso
Relaciones y vínculos estructurales especificados por el Estado
Relación y vínculo de caracterización especificados por estado : una relación de caracterización de exhibición de un objeto especializado que exhibe un valor para un atributo discriminante de ese objeto, lo que significa que el objeto especializado solo tendrá ese valor. Gráficamente, el símbolo triangular de vínculo de caracterización de exhibición, con su vértice conectado al objeto especializado y su base opuesta conectada al valor, define la relación de caracterización especificada por estado. La sintaxis es: objeto especializado exhibe nombre-valor nombre-atributo.
Relaciones estructurales y enlaces etiquetados especificados por estado : una relación estructural entre un estado de un objeto o valor de un atributo y otro objeto o su estado o valor, lo que significa que estas dos entidades están asociadas con la etiqueta que expresa la semántica de la asociación. En caso de una etiqueta nula (es decir, la etiqueta no está especificada), se utiliza la etiqueta nula predeterminada correspondiente. Existen tres grupos de relaciones estructurales etiquetadas especificadas por estado: (1) relación estructural etiquetada especificada por estado de origen, (2) relación estructural etiquetada especificada por estado de destino, (3) relación estructural etiquetada especificada por estado de origen y destino. Cada uno de estos grupos incluye la relación estructural etiquetada unidireccional, bidireccional y recíproca apropiada, lo que da lugar a siete tipos de enlace de relación estructural etiquetada especificada por estado y las sentencias OPL correspondientes.
Se puede encontrar más información y ejemplos en Ingeniería de sistemas basada en modelos con OPM y SysML , Capítulo 3.3 "Adición de vínculos estructurales". [4]
Cardinalidades de relación
Multiplicidad de objetos en vínculos estructurales y procedimentales
La multiplicidad de objetos se referirá a una especificación de requisito o restricción sobre la cantidad o recuento de instancias de objetos asociadas con un enlace. A menos que exista una especificación de multiplicidad, cada extremo de un enlace deberá especificar solo una instancia de objeto. La sintaxis de una oración OPL que incluye un objeto con multiplicidad deberá incluir la multiplicidad de objetos antes del nombre del objeto, y el nombre del objeto aparecerá en su forma plural. Las especificaciones de multiplicidad pueden aparecer en los siguientes casos:
para especificar múltiples instancias de objetos de origen o destino para un enlace estructural etiquetado de cualquier tipo;
para especificar un objeto participante con múltiples instancias en un enlace de agregación-participación, donde se puede adjuntar una especificación de participación diferente a cada una de las partes del todo;
para especificar un objeto con múltiples instancias en una relación procedimental.
Expresiones y restricciones de multiplicidad de objetos
La multiplicidad de objetos puede incluir expresiones aritméticas, que utilizarán los símbolos operadores "+", "–", "*", "/", "(" y ")" con su semántica habitual y utilizarán la correspondencia textual habitual en las oraciones OPL correspondientes.
Un entero o una expresión aritmética pueden restringir la multiplicidad de objetos. Gráficamente, las restricciones de expresión deben aparecer después de un punto y coma que las separa de la expresión que restringen y deben usar los símbolos de igualdad/desigualdad "=", "<", ">", "<=" y ">=", las llaves "{" y "}" para encerrar los miembros del conjunto y el operador de pertenencia "in" (elemento de, ∈), todos con su semántica habitual. La oración OPL correspondiente debe colocar la frase de restricción en letras negritas después del objeto al que se aplica la restricción en la forma ", donde restricción".
Restricciones de valor de atributo y multiplicidad
La expresión de multiplicidad de objetos para enlaces estructurales y procedimentales especifica valores enteros o símbolos de parámetros que se resuelven en valores enteros. Por el contrario, los valores asociados con atributos de objetos o procesos pueden ser valores enteros o reales, o símbolos de parámetros que se resuelven en valores enteros o reales, así como cadenas de caracteres y valores enumerados. Gráficamente, un rectángulo etiquetado con esquinas redondeadas colocado dentro del atributo al que pertenece denotará un valor de atributo con el valor o rango de valores (enteros, números reales o caracteres de cadena) correspondiente al nombre de la etiqueta. En el texto OPL, el valor del atributo aparecerá en negrita sin mayúsculas.
La sintaxis para un objeto con una sentencia OPL de valor de atributo será: El atributo del objeto es valor .
La sintaxis para un objeto con una sentencia OPL de rango de valores de atributo debe ser: El rango de atributos del objeto es rango-de-valores . Un vínculo estructural o procedimental que se conecta con un atributo que tiene un valor de número real puede especificar una restricción de relación, que es distinta de una multiplicidad de objetos.
Gráficamente, una restricción de valor de atributo es una anotación mediante un número, entero o real, o un parámetro de símbolo, cerca del extremo del atributo del enlace y alineado con el enlace.
Operadores lógicos: AND, XOR y OR
Enlaces lógicos y procedimentales
Los operadores lógicos AND, XOR y OR entre las relaciones procedimentales permiten la especificación de condiciones previas y posteriores elaboradas para el proceso. Los vínculos separados que no se tocan deben tener la semántica del operador lógico AND. En este caso, para abrir la caja fuerte se necesitan las tres llaves.
Enlaces procedimentales lógicos XOR y OR
Un abanico de enlaces debe seguir la semántica de un operador XOR o de un operador OR. El extremo del abanico de enlaces que sea común a los enlaces será el extremo del enlace convergente. El extremo del enlace que no sea común a los enlaces será el extremo del enlace divergente.
El operador XOR significará que existe exactamente una de las cosas en el intervalo del abanico de enlaces, si el extremo del enlace divergente tiene objetos, o que sucede, si el extremo del enlace divergente tiene procesos. Gráficamente, un arco discontinuo que atraviesa los enlaces en el abanico de enlaces con el punto focal del arco en el punto de contacto del extremo convergente denotará el operador XOR.
El operador OR significa que al menos una de las dos o más cosas en el tramo del abanico de enlaces existe, si el extremo del enlace divergente tiene objetos, o sucede, si el extremo divergente tiene procesos. Gráficamente, dos arcos discontinuos concéntricos a través de los enlaces con su punto focal en el punto de contacto del extremo convergente denotarán el operador OR.
Abanicos de enlaces XOR y OR especificados por estado
Ventiladores de enlace modificados por control
Probabilidades de enlace y abanicos de enlaces probabilísticos
Ruta de ejecución y etiquetas de ruta
Una etiqueta de ruta será una etiqueta a lo largo de un enlace de procedimiento, la cual, en el caso de que exista más de una opción a seguir al finalizar el proceso, prescribe que el enlace a seguir será el que tenga la misma etiqueta que el que ingresamos al proceso.
Principios de modelado y comprensión de modelos
La definición del propósito, alcance y función del sistema en términos de límites, partes interesadas y condiciones previas es la base para determinar si otros elementos deben aparecer en el modelo. Esto determina el alcance del modelo del sistema. OPM proporciona mecanismos de abstracción y refinamiento para gestionar la expresión de la claridad y completitud del modelo. [1] [4]
Identificación de las partes interesadas y beneficiarios del sistema
En el caso de los sistemas creados por el hombre, se espera que esta función beneficie a una persona o a un grupo de personas (el beneficiario). Una vez que la función del sistema se alinea con la expectativa de valor funcional de su principal beneficiario, el modelador identifica y agrega otras partes interesadas principales al modelo OPM.
Diagrama del sistema
El OPD de nivel superior resultante es el diagrama del sistema (SD), que incluye el grupo de partes interesadas, en particular el grupo de beneficiarios, y elementos ambientales de nivel superior adicionales, que proporcionan el contexto para el funcionamiento del sistema. El SD debe contener solo los elementos centrales e importantes, aquellos elementos indispensables para comprender la función y el contexto del sistema. La función es el proceso principal en SD, que también contiene los objetos involucrados en este proceso: el beneficiario, el operando (el objeto sobre el que opera el proceso) y, posiblemente, el atributo del operando cuyo valor cambia el proceso. SD también debe contener un objeto que represente el sistema que habilita la función. El nombre predeterminado de este sistema se crea agregando la palabra "Sistema" al nombre de la función. Por ejemplo, si la función es Pintura de autos, el nombre del sistema sería Sistema de Pintura de Autos.
Árbol OPD
Compromiso entre claridad y completitud
Para establecer un equilibrio adecuado es necesario gestionar cuidadosamente el contexto durante el desarrollo del modelo. Sin embargo, el modelador puede aprovechar la unión de la información proporcionada por todo el conjunto OPD de un modelo de sistema OPM y tener un OPD claro e inequívoco pero no completo, y otro que se centre en la integridad de una parte más pequeña del sistema añadiendo más detalles.
Mecanismos de refinamiento-abstracción
La OPM debe proporcionar mecanismos de abstracción y refinamiento para gestionar la expresión de la claridad y completitud del modelo. Estos mecanismos deben permitir la presentación y visualización del sistema y de las cosas que lo componen en diversos contextos que están interrelacionados por los objetos, procesos y relaciones que son comunes entre ellos.
Expresión estatal y represión estatal
La operación inversa de la supresión de estado será la expresión de estado, es decir, el refinamiento del OPD añadiendo la información relativa a los posibles estados de los objetos. El OPL correspondiente al OPD expresará únicamente los estados de los objetos representados.
Desplegado y plegado
Revela un conjunto de cosas que están jerárquicamente por debajo de la cosa desplegada. El resultado es un árbol jerárquico cuya raíz es la cosa desplegada. Vinculadas a la raíz están las cosas que constituyen el contexto de la cosa desplegada. Por el contrario, el plegado es un mecanismo de abstracción o composición, que se aplica a un árbol jerárquico desplegado.
Acercar y alejar la imagen
El acercamiento es un tipo de despliegue que se aplica únicamente a la participación en agregaciones y tiene una semántica adicional. En el caso de los procesos, el acercamiento permite modelar los subprocesos, su orden temporal, sus interacciones con los objetos y la transferencia del control hacia y desde este contexto. En el caso de los objetos, el acercamiento crea un contexto distinto que permite modelar el orden espacial o lógico de los objetos constituyentes. Gráficamente, la línea de tiempo dentro del contexto de un proceso ampliado fluye desde la parte superior de su símbolo de elipse de proceso hasta la parte inferior de la elipse.
Modelado meta
Estructura del modelo OPM
Modelo de constructo OPD y constructo básico
El modelo, como se ve en la imagen del metamodelo OPD, elabora el concepto de Constructo OPD. El propósito de este modelo es distinguir el Constructo Básico de otro posible Constructo OPD. Un Constructo Básico es una especialización del Constructo OPD, que consiste en exactamente dos Cosas conectadas por exactamente un Vínculo. Los constructos no básicos incluyen, entre otros, aquellos con abanicos de vínculos o más de dos refinados.
Un modelador podría añadir un proceso al modelo, añadiendo estados desconectados y conectados del conjunto de cosas. El objetivo del modelo incluye, por tanto, la acción de transformar un conjunto de cosas desconectado en un conjunto de cosas conectado utilizando el conjunto de vínculos como instrumento de conexión.
Modelo OPM de Cosa
El modelo OPM de cosa es un modelo para una cosa OPM, que muestra su especialización en objeto y proceso, como se muestra en la imagen del modelo de cosa a continuación. Un conjunto de estados caracteriza al objeto, que puede estar vacío, en el caso de un objeto sin estado, o no vacío en el caso de un objeto con estado.
Un objeto con estado con s estados da lugar a un conjunto de s objetos específicos de estado sin estado, uno para cada estado. Un objeto específico de estado particular hace referencia a un objeto en un estado específico. Modelar el concepto de objeto específico de estado como un objeto y un estado permite simplificar el modelo conceptual haciendo referencia a un objeto y a cualquiera de sus estados simplemente especificando Objeto.
Modelo OPM de propiedades genéricas de cosas
El modelo OPM de propiedades genéricas de Cosa describe la Cosa y sus propiedades genéricas de Perseverancia, Esencia y Afiliación modeladas como atributos refinados de un vínculo de exhibición-caracterización. La Perseverancia es el atributo discriminante entre Objeto y Proceso.
Modelos con zoom hacia adentro y hacia afuera
Tanto el acercamiento como el alejamiento de un nuevo diagrama crean un nuevo contexto OPD a partir de un contexto OPD existente. El acercamiento comienza con un OPD de relativamente menos detalles y agrega elaboración o refinamiento como un OPD descendiente que se aplica a una cosa específica en el OPD menos detallado.
Versiones
OPM
La versión actual de OPM es ISO/PAS 19450:2015, tal como se especifica en Automation Systems and Integration — Object-Process Methodology. [1] La especificación del libro de Dori de 2016 es un superconjunto de ISO/PAS 19450:2015. [4]
La versión anterior de OPM se especificó en el libro de Dori de 2002. [3]
OPCAT
La versión actual de OPCAT es la 4.1. Está disponible de forma gratuita en el Laboratorio de Modelado de Sistemas Empresariales del Technion. [5]
También está disponible en el mismo sitio una versión anterior de OPCAT, la 3.1, con menos funciones. Ambas están codificadas en Java. La primera versión de OPCAT, OPCAT 1.X, se escribió en Visual C++ en 1998.
A principios de 2016, un equipo de estudiantes bajo la dirección de Dori comenzó a trabajar en la nueva generación de OPCAT, que se llamará OPCloud. [13] Como sugiere el nombre del software, será una aplicación basada en la nube y permitirá a los usuarios crear modelos OPM utilizando una aplicación basada en la web. [14]
Normalización
La ISO (Organización Internacional de Normalización) es una organización internacional independiente y no gubernamental integrada por 162 organismos nacionales de normalización, que desarrolla normas internacionales voluntarias, basadas en el consenso y relevantes para el mercado que apoyan la innovación y ofrecen soluciones a los desafíos globales. Estas normas proporcionan especificaciones de clase mundial para productos, servicios y sistemas, con el fin de garantizar la calidad, la seguridad y la eficiencia.
ISO y OPM
En junio de 2008, Richard Martin se acercó a Dov Dori después de su presentación en el Simposio Internacional INCOSE en Utrecht, Países Bajos, para preguntar sobre la posibilidad de crear una Norma Internacional para OPM. [15] Martin, coordinador de ISO TC184/SC5/WG1 para la arquitectura y modelado de interoperabilidad de sistemas de automatización, había estado buscando durante algún tiempo metodologías que ofrecieran más que información estática y modelado de procesos. [ cita requerida ] Le proporcionó a Dori un ejemplo simple para modelar que pudiera demostrar tanto la capacidad de modelado de OPM como su oportunidad de simulación dinámica. [ cita requerida ]
En mayo de 2010, Dori presentó una breve descripción general de la OPM y su modelo de demostración en la reunión plenaria del Comité Técnico 184/Subcomité 5 (TC184/SC5) de la ISO, que luego adoptó una resolución para crear un Grupo de Estudio de la OPM con el propósito de examinar el potencial de la OPM para mejorar las normas creadas por el SC5. [16]
El Grupo de Estudio de la OPM comenzó su trabajo en octubre de 2010 y publicó un informe provisional para la sesión plenaria del SC5 de 2011. [15] El informe incluía varios usos de la OPM para modelar las normas existentes del SC5 y dio lugar a una motivación inicial para la normalización de la OPM con la constatación de que, al estar basadas en texto, las normas ISO son propensas a sufrir inconsistencias e información incompleta. Esta deficiencia podría reducirse significativamente si las normas se basaran en modelos en lugar de texto, y la OPM ofrecía un paradigma de modelado subyacente útil para este propósito.
En la sesión plenaria del SC5 de 2012 se presentó un informe final del Grupo de Estudio de la OPM y un borrador de un metamodelo para el documento de creación de estándares basados en modelos. [17] A medida que avanzaba el esfuerzo del Grupo de Estudio de la OPM, se hizo evidente que la OPM también podía servir como una base sólida y completa para la ingeniería de sistemas basada en modelos (MBSE) y para modelar sistemas tanto naturales como artificiales. [ cita requerida ]
Documento ISO 19450
Los participantes del TC184/SC5/WG1 recibieron el primer borrador del OPM PAS en septiembre de 2011 con 16 páginas, 2 anexos y una bibliografía para un total de 25 páginas. [ cita requerida ] La mayor parte del contenido simplemente identificaba los encabezados de las subcláusulas y los gráficos de retención de espacios. [ cita requerida ] Para la sesión plenaria del SC5 de 2012, el borrador del PAS incluía 10 cláusulas completas que describían las características del OPM y 6 anexos con un total de 86 páginas. [ cita requerida ] Un anexo era una especificación EBNF (forma Backus-Naur extendida, utilizada para especificar formalmente lenguajes libres de contexto, lo que permite el análisis de lenguajes de programación) para OPL y otra gramática gráfica OPD detallada. Para facilitar la verificación de la especificación EBNF, David Shorter escribió un script para evaluar la consistencia y la integridad del conjunto de declaraciones EBNF. [ cita requerida ] Un esfuerzo adicional para agregar ejemplos significativos y completar todas las secciones identificadas dio como resultado un borrador de 138 páginas al momento de la sesión plenaria del SC5 de 2013. [ cita requerida ] Posteriormente, el borrador de trabajo se registró en la Secretaría del SC5 como Borrador del Comité para su circulación inicial a los miembros del SC5. [ cita requerida ]
Debido a que la resolución del SC5 que solicitaba la especificación OPM indicaba que el documento debía registrarse como una Especificación Disponible al Público (PAS), solo tendría una oportunidad de votación de aceptación. En abril de 2014, la Propuesta de Nuevo Elemento de Trabajo y el Borrador de Comité revisado para ISO/PAS 19450 se entregaron al SC5 para su consideración. [ cita requerida ] En ese momento, el Borrador de Comité tenía 98 páginas más material preliminar, cuatro anexos y 30 referencias bibliográficas, lo que totalizaba 183 páginas. [ cita requerida ] En marzo de 2015, ISO registró el resultado de la votación para ISO/PAS 19450 como 8 Aprobado, 1 Aprobado con comentarios y 1 abstención. [ cita requerida ]
La norma ISO/PAS 19450 se publicó formalmente con un total de 162 páginas por ISO el 15 de diciembre de 2015, culminando un esfuerzo de seis años para proporcionar a la comunidad de estandarización una especificación formal para un nuevo enfoque de modelado que une gráficos y representaciones textuales en un único paradigma adecuado para la simulación automatizada del comportamiento del modelo.
Las diferencias entre OPM y UML son muy perceptibles durante las etapas de análisis y diseño. Mientras que UML es un modelo múltiple, OPM admite un único modelo unificador de estructura-comportamiento. Las diferencias cruciales surgen del enfoque orientado a la estructura de UML, en el que el comportamiento se distribuye en trece tipos de diagramas, un hecho que inevitablemente invoca el problema de multiplicidad de modelos. [18] En primer lugar, el uso del enfoque OPM permite ver en el diagrama principal (SD) el proceso principal, los objetos y la conexión entre ellos. [3] [ página necesaria ] Además, es fácil entender cuál es el beneficio principal del sistema (presentado en el SD). En OPM, también es más fácil entender los tres aspectos principales del sistema: comportamiento, estructura y funcionalidad (al contrario de UML que describe estos aspectos con diferentes tipos de diagramas). [3] [ página necesaria ] El modelado de despliegue de base de datos contribuye a la comprensión del sistema y todos los detalles que se almacenan en el sistema. Además, la creación de zoom permite simplificar el modelo. OPM requiere un amplio conocimiento de los procesos sistemáticos, como la forma en que el sistema guarda la ruta y toma decisiones.
Generación de vistas SysML a partir de un modelo OPM
Si bien ambos lenguajes tienen el mismo objetivo de proporcionar un medio para la ingeniería de sistemas de propósito general, estos lenguajes adoptan diferentes enfoques para lograr este objetivo. SysML es un perfil de UML (lenguaje de modelado unificado).
La traducción de OPM a SysML es de uno a muchos en el sentido de que un solo elemento OPM (entidad o enlace) suele traducirse en varios elementos SysML que pertenecen a diferentes tipos de diagramas SysML. Por ejemplo, un proceso OPM, que se define como una entidad que transforma (genera, consume o cambia el estado de) un objeto, se puede asignar a cualquier subconjunto de las siguientes entidades SysML:
Disparador de transición de estado (en un diagrama de máquina de estados).
Como OPM y SysML son dos lenguajes distintos y diseñados de forma diferente, no todas las construcciones de un lenguaje tienen construcciones equivalentes en el otro lenguaje.
El primer tipo de diagrama en UML que se puede generar a partir de un diagrama OPM es el diagrama de casos de uso, cuyo objetivo es modelar el uso de un sistema. Los elementos principales que componen el diagrama de casos de uso son los actores y los casos de uso (las entidades) junto con las relaciones (vínculos) entre ellos. Por lo tanto, la generación de un diagrama de casos de uso a partir de OPM se basa en objetos ambientales (los actores) y los procesos (los casos de uso) vinculados a ellos. La figura 1 es un ejemplo de generación de diagrama de casos de uso de SD0. La figura muestra el diagrama OPM raíz (a), el texto OPL correspondiente (b) y el diagrama de casos de uso creado (c). La figura 2 muestra un nivel SD1 de OPD a partir del mismo modelo OPM (a) y el diagrama de casos de uso generado (b).
El segundo tipo de diagrama es el diagrama de definición de bloques (BDD), que define las características de los bloques (como propiedades y operaciones) y las relaciones entre bloques, como asociaciones y generalizaciones. La generación de un BDD se basa en los objetos sistémicos del modelo OPM y sus relaciones, principalmente relaciones estructurales con otros elementos del modelo.
El tercer tipo de diagrama son los diagramas de actividades, que tienen como objetivo especificar el flujo. Los componentes clave incluidos en el diagrama de actividades son las acciones y los elementos de flujo de enrutamiento. En nuestro contexto, se puede generar un diagrama de actividades independiente para cada proceso OPM que contenga subprocesos secundarios, es decir, un proceso que se amplía en el modelo OPM. Hay dos tipos de parámetros de usuario que se pueden especificar a través del cuadro de diálogo de configuración. El primero se ocupa de la selección de los procesos OPM: una opción es especificar explícitamente los procesos OPM necesarios mediante la selección de una lista. La alternativa, que es la opción predeterminada, es comenzar con el OPD raíz (SD) y descender por la jerarquía. Aquí llegamos al segundo parámetro (que es independiente del primero), que es el número necesario de niveles OPD (k) para descender por la jerarquía. Para dar al usuario control sobre el nivel de abstracción, los diagramas se generan hasta k niveles por debajo de la jerarquía. Cada nivel dará como resultado la generación de un diagrama de actividades adicional, que es una actividad secundaria (subdiagrama) contenida en la actividad de nivel superior que la encierra. La configuración predeterminada para esta opción es "todos los niveles hacia abajo" (es decir, "k = ∞"). [19]
^ abcde «ISO/PAS 19450:2015 - Sistemas de automatización e integración - Metodología objeto-proceso». iso.org . Diciembre de 2015 . Consultado el 3 de mayo de 2017 .
^ ab Dori, Dov (1995). "Análisis de objetos y procesos: mantenimiento del equilibrio entre la estructura y el comportamiento del sistema". Journal of Logic and Computation . 5 (2): 227–249. doi :10.1093/logcom/5.2.227.
^ abcde Dori, Dov (2002). Metodología de objetos y procesos: un paradigma sistémico holístico . Berlín, Heidelberg, Nueva York: Springer-Verlag . doi :10.1007/978-3-642-56209-9. ISBN978-3540654711.S2CID13600128 .
^ abc "Laboratorio de modelado de sistemas empresariales » Instalación de OPCAT". technion.ac.il . Consultado el 3 de mayo de 2017 .
^ Booch, G. "Es hora de un alto el fuego en la guerra de métodos". Journal of Object-Oriented Programming , julio/agosto de 1993.
^ Perelman, Valeria; Somekh, Judith; Dori, Dov (2011). Marco de verificación de modelos con aplicación a la biología molecular. TMS-Devs '11. Sociedad para la Simulación Computacional Internacional. págs. 140–145.
^ Fischer, Amit; Nolan, Mike; Friedenthal, Sanford; Loeffler, Michael; Sampson, Mark; Bajaj, Manas; VanZandt, Lonnie; Hovey, Krista; Palmer, John; Hart, Laura (2014). "3.1.1 Gestión del ciclo de vida del modelo para MBSE". Simposio internacional INCOSE . 24 : 207–229. doi :10.1002/j.2334-5837.2014.tb03145.x. S2CID 106677531.
^ Véase también: Herre, Heinrich; Heller, Barbara; Burek, Patryk; Hoehndorf, Robert; Loebe, Frank; Michalek, Hannes (julio de 2006). "Ontología formal general (GFO): una ontología fundacional que integra objetos y procesos: parte I: principios básicos" (PDF) . Onto-Med Report . 8 : 3. Los lenguajes actuales en uso para el modelado conceptual como el Lenguaje de Modelado Unificado (UML), el modelado de entidad-relación en el campo de las bases de datos o la Metodología Objeto-Proceso pueden examinarse de acuerdo con sus compromisos ontológicos.
^ Dori, Dov; Linchevski, Chen; Manor, Raanan (2010). "OPCAT – Un entorno de software para el modelado conceptual de sistemas complejos basado en la metodología de procesos de objetos". Proc. 1.ª Conferencia internacional sobre modelado y gestión de procesos de ingeniería . Universidad de Cambridge, Cambridge, Reino Unido, Heisig, P., Clarkson, J. y Vajna, S. (Eds.): 147–151.
^ ab Grobshtein, Yariv; Perelman, Valeriya; Safra, Eliyahu; Dori, Dov (2007). Lenguajes de modelado de sistemas: OPM versus SysML. Haifa, Israel: IEEE. págs. 102-109. ISBN978-1-4244-0770-5Archivado del original el 18 de febrero de 2020 . Consultado el 15 de noviembre de 2018 .
^ Véase también: "El ciclo de vida del ARNm" (PDF) . technion.ac.il . Consultado el 3 de mayo de 2017 .
^ Laboratorio de Modelado de Sistemas Empresariales. "opcloud".
^ Dori, Dov; Jbara, Ahmad; Levi, Natali; Wengrowicz, Niva. "Metodología de objetos y procesos, OPM ISO 19450 – OPCloud y la evolución de las herramientas de modelado de OPM". Project Performance International . Consultado el 18 de noviembre de 2018 .
^ ab Blekhman, Alex; Dori, Dov; Martin, Richard. "Creación de estándares basados en modelos" (PDF) . Consultado el 18 de noviembre de 2018 .
^ Dori, Dov; Howes, David; Blekhman, Alex; Martin, Richard. "OPM como base para estándares empresariales basados en modelos, Informe del Grupo de trabajo OPM del TC184/SC5 de ISO a la reunión plenaria del TC184/SC5 de ISO, Tokio, 26 de noviembre de 2010" (PDF) . Consultado el 18 de noviembre de 2018 .
^ SESIÓN PLENARIA DEL SC 5. "Informe de la reunión" (PDF) . Consultado el 18 de noviembre de 2018 .{{cite web}}: CS1 maint: numeric names: authors list (link)
^ Peleg, M.; Dori, D. (2000). "El problema de la multiplicidad de modelos: experimentación con métodos de especificación en tiempo real". IEEE Transactions on Software Engineering . 26 (8): 742–759. CiteSeerX 10.1.1.321.5507 . doi :10.1109/32.879812.
^ Grobshtein, Yariv; Dori, Dov (2009). Creando vistas SysML a partir de un modelo OPM . Haifa, Israel: IEEE. págs. 36–44. doi :10.1109/MBSE.2009.5031718. ISBN978-1-4244-2967-7.S2CID6195904 .
Enlaces externos
Wikimedia Commons tiene medios relacionados con Metodología de Procesos de Objetos .
Metodología Objeto-Proceso y su aplicación a la Web Semántica Visual, presentación de Dov Dori, 2003.
Algunas características del lenguaje técnico de Navya-Nyāya
Formalización del proceso de pensamiento de modelado conceptual para beneficiar a ingenieros y científicos, presentación de Dov Dori, 2015.
Formalización del proceso de pensamiento del modelado conceptual para beneficiar a ingenieros y científicos
Patente estadounidense US7099809B2 sobre conversión de OPD a y desde formatos de texto