객체 프로세스 방법론
Object Process Methodology![]() | 이 글에는 여러 가지 문제가 있다.이 문제를 개선하거나 대화 페이지에서 토의하십시오.(이러한 템플릿 메시지를 제거하는 방법 및 시기 알아보기)
|
![]() |
정보 매핑 |
---|
주제 및 필드 |
노드 링크 접근 방식 |
참고 항목 |
OPM(Object Process Methodology)은 지식을 포착하고 시스템을 설계하기 위한 개념 모델링 언어 및 방법론이며 ISO/PAS 19450으로 지정된다.[1]OPM은 상태 저장 객체와 이를 변형시키는 프로세스의 최소한의 보편적 온톨로지(universal ontology)에 기초해 다양한 영역에서 인공 및 자연 시스템의 기능, 구조, 행동을 공식적으로 규정하는 데 사용할 수 있다.
OPM은 도브 도리에 의해 고안되고 개발되었다.OPM의 기초가 되는 아이디어는 1995년에 처음으로 출판되었다.[2]그 이후로 OPM은 진화, 발전해 왔다.
2002년에 OPM에[3] 관한 첫 번째 책이 출판되었고, 2015년 12월 15일 ISO TC184/SC5의 6년간의 작업 끝에 ISO/PAS 19450으로 OPM을 채택하였다.[1]OPM에 관한 두 번째 책이 2016년에 출판되었다.[4]
OPM은 2019년부터 EdX에서 모델 기반 시스템 엔지니어링 - MBSE의 프로페셔널 인증 프로그램의 기반이 되었다.유튜브에서 웹 동영상으로 강의가 가능하다.
개요
OPM(Object Process Methodology)은 지식을 포착하고 시스템을 설계하기 위한 개념 모델링 언어 및 방법론이다.OPM은 상태 저장 객체와 이를 변형시키는 프로세스의 최소한의 보편적 온톨로지(universal ontology)에 기초해 다양한 영역에서 인공 및 자연 시스템의 기능, 구조, 행동을 공식적으로 규정하는 데 사용할 수 있다.인간의 인지 능력에 맞춰 OPM 모델은 표현, 이해, 의사소통 및 학습 개선을 위해 그래픽과 텍스트 모두에서 설계 또는 양방향으로 연구 중인 시스템을 나타낸다.
OPM에서 존재하거나 존재하지 않는 모든 사물.개체는 상태 저장(stateful)이다. 각 시점에서 개체가 상태 중 하나에 있거나 상태 간에 전환 중인 상태일 수 있다.과정은 물체를 창조하거나 소비하거나 상태를 변화시킴으로써 물체를 변형시키는 것이다.
OPM은 양방향이다. OPD(Object-Process Diagraphes, OPL)로 시각/그래픽적으로 표현되며, 언어/문자로 표현된다. OPL(Object-Process Language, OPL)은 영어의 서브셋으로 자동 생성된 문장 집합이다.OPD와 OPL 생성을 위한 특허 소프트웨어 패키지인 OPCAT를 무료로 이용할 수 있다.[5]
역사
1980년대와 1990년대에 일어났던 컴퓨터 프로그래밍 언어의 객체지향적(OO) 패러다임으로의 전환은, 프로그램의 객체지향적 분석과 설계가 선행되어야 한다는 생각, 그리고 더 일반적으로는, 그 프로그램들이 나타내고 서비스하는 시스템들이 선행되어야 한다는 생각이 뒤따랐다.따라서 1990년대 초에는 30여 개의 객체지향적 분석과 설계방법과 공명이 번성하여 이른바 '방법전쟁'으로까지 알려지게 되었다.[6]
— Dov Dori, "Preface", Model-Based Systems Engineering with OPM and SysML (2017)
그 무렵 1991년 당시 테크니온-이스라엘 공과대학에 교수로 입사했던 도브 도리는 2016년 저서 OPM과 SysML에서 다음과 같이 말했다.
소프트웨어에 대한 절차적 접근방식이 불충분했던 것처럼, "방법" (또는 "서비스")이 그들의 2급 하위절차인 "방법" (또는 "서비스")를 가진 유일한 "제1급" 시민으로 사물을 두는 "순수한" OO 접근방식도 마찬가지라는 것을 깨달았다.
— Dov Dori, "Preface", Model-Based Systems Engineering with OPM and SysML (2017)
도리는 1995년에 OPM에 대한 첫 번째 논문을 발표했다.[2]
1997년 OMG(Object Management Group)에 의한 통합 모델링 언어(UML)가 소프트웨어 설계의 사실상의 표준이 되었다.UML 1.1은 1997년 8월에 OMG에 제출되었고 1997년 11월에 OMG에 의해 채택되었다.
OPM에 관한 첫 번째 책인 객체-프로세스 방법론: 전체론적 시스템 패러다임이 2002년에 출판되었고,[3] 이후 OPM은 많은 도메인에서 적용되었다.[7][8]
2014년 8월에 ISO는 OPM을 ISO/PAS 19450으로 채택하였다.[1]
SysML도 다루는 OPM에 관한 두 번째 책이 2016년에 출판되었다.[4]
디자인
OPM(Object-Process Methodology, OPM)은 어떤 시스템에 내재된 두 가지 측면, 즉 그것의 구조와 그 행동과 통합되는 시스템 모델링 패러다임이다.구조는 집합 참여(whole-part relationship)와 일반화-특수화("is-a" relationship)와 같이 개체와 그 사이의 구조적 관계를 통해 표현된다.동작은 프로세스와 프로세스에서 객체를 변환하는 방법에 의해 표현된다.개체를 생성하거나 소비하는 방법 또는 개체의 상태를 변경하는 방법.[4]: 2
OPM은 인공적이든 자연적이든 거의 모든 영역의 시스템을 모델링하는 방법을 제공한다.[4]: x [9]
모델링.
OPM은 OPD(Object Process Language)와 해당 문장의 집합으로 구성되어 있으며, OPL(Object Process Language)이라고 불린다.OPL은 OPM에서 모델링을 지원하는 소프트웨어 도구인 [5]OPCAT에 의해 자동으로 생성된다.[10]
- 객체 프로세스 다이어그램(OPD)
OPD는 OPM의 유일한 종류의 다이어그램이다.이러한 다이어그램 종류의 고유성은 OPM의 단순성에 큰 기여를 하고 있으며, 14종의 다이어그램이 있는 UML과 9종의 다이어그램이 있는 SysML과는 뚜렷한 대조를 이룬다.[11]OPD는 객체, 프로세스 및 그들 사이의 링크를 그래픽으로 설명한다.링크는 구조적이고 절차적일 수 있다.구조적 연결은 물체와 프로세스를 프로세스와 연결시켜 정적 시스템 측면, 즉 시스템이 어떻게 구조되는지를 표현한다.절차적 링크는 시간에 따라 시스템이 어떻게 변화하는지 동적 시스템 측면을 표현하면서 객체를 프로세스에 연결한다.전체 시스템은 시스템 다이어그램(SD)이라 불리는 루트 OPD가 시스템의 "새의 눈" 보기를 지정하고 하위 수준의 OPD가 시스템을 증가하는 세부 수준으로 지정하는 등 계층적으로 구성된 OPD 세트로 표현된다.시스템의 OPD 세트에 있는 모든 OPD는 서로 "인식"하며, 각 OPD는 시스템 또는 그 일부를 어느 정도 세부적인 수준에서 보여준다.전체 시스템은 모든 OPD에 나타나는 세부사항(모델 사실)의 결합에 의해 전체로 지정된다.
- OPL(Object Process Language)
각 OPD 구성물(즉, 하나 이상의 링크로 연결된 두 개 이상의 것)은 자연영어의 하위 집합인 OPL로 된 문장으로 번역된다.OPL의 힘은 인간이 읽을 수 있지만 컴퓨터로도 해석할 수 있다는 사실에 있다.이러한 단계는 가장 중요한 설계 결정이 이루어지는 단계다.OPM의 그래픽 텍스트 양면성은 고객 또는 그의 도메인 전문가와 시스템 설계자, 모델러 및 설계자 모두를 포함하는 팀이 요구사항을 공동으로 모델링하는 데 적합하다.[4]: 3
- OPM 모델 애니메이션 시뮬레이션
OPM 모델은 시스템의 정적 그래픽 및 텍스트 표현일 뿐만 아니라 실행 가능하다.OPCAT에 구축된 정확한 OPM 모델은 이를 애니메이션화하여 시뮬레이션할 수 있으며, 모든 세부 수준에서 기능을 달성하기 위해 시스템이 시간에 따라 어떻게 동작하는지를 시각적으로 표현한다.부정확한 OPM 모델은 끝까지 실행되지 않을 것이며, 어디에, 왜 그것이 고착되어 있는지 표시하여 사실상 시각적 디버거의 역할을 할 것이다.
개발
OPM과 SysML을 가진 도리의 책 모델 기반 시스템 엔지니어링에 대한 그의 서문에서 Edward F. 크롤리는 이렇게 말했다.
OPM 의미론은 원래 정보, 하드웨어, 인력 및 규제를 모델링할 수 있기 때문에 시스템 엔지니어링에 맞춰져 있었다.그러나 최근 몇 년 동안 OPM은 mRNA 라이프사이클과 관련하여 새로 발표된 연구 결과를 도출하면서 분자생물학 연구자들에게도 서비스를 제공하기 시작했다.이것은 개체와 프로세스 온톨로지의 보편성을 분명하게 보여주는 것이다.[4]: vi [12]
기본 사항
OPM은 언어와 방법론의 두 가지 주요 부분을 가지고 있다.언어는 양방향이다. 즉, 두 가지 보완적 방법(양식)으로 표현된다. 시각적, 그래픽적 부분, 즉 하나 이상의 OPD(Object-Process Language)의 집합과 해당 텍스트 부분, 즉 영어의 하위 집합인 OPL(Object-Process Language)의 문장 집합이다.
최상위 OPD는 시스템 기능에 대한 맥락을 제공하는 시스템 다이어그램(SD)이다.인공 시스템의 경우, 이 기능은 개인이나 그룹의 사람들, 즉 수혜자에게 이익이 될 것으로 예상된다.함수는 SD의 주요 프로세스로서, 또한 이 프로세스와 관련된 대상들, 즉 수혜자, 피연산자(프로세스가 작동하는 개체), 그리고 아마도 프로세스의 가치가 변하는 속성을 포함한다.
OPM 그래픽 요소는 폐쇄형 모양으로 표현되는 실체와 실체를 연결하는 링크로서 표현되는 관계로 구분된다.
엔티티
실체는 OPM의 구성 요소다.그것들은 집합적으로 사물과 객체 상태라고 불리는 사물들과 과정들을 포함한다.
- 오브젝트
- 객체 간의 연관성은 모델링되는 시스템의 객체 구조를 구성한다.OPL 텍스트에서 객체 이름은 각 단어의 대문자로 굵은 글씨로 표시되어야 한다.
- 객체 상태
- 객체 상태는 물체의 수명 중 어느 시점에서 물체의 특정한 상황 분류다.모든 시점에서 물체는 그 상태 중 하나에 있거나 입력 상태에서 출력 상태로 두 상태 사이에서 전환 중에 있다.
- 과정
- 프로세스는 시스템 내 객체의 변환 패턴을 표현한 것이다.프로세스는 격리된 상태로 존재하지 않으며, 프로세스는 항상 하나 이상의 개체와 연관되어 발생하거나 발생한다.프로세스는 객체를 생성하거나, 소비하거나, 상태를 변경하여 객체를 변환한다.그러므로 공정은 시스템의 동적인 행동적 측면을 제공함으로써 사물을 보완한다.OPL 텍스트에서 프로세스 이름은 각 단어의 대문자로 굵게 표시되어야 한다.
링크
- 구조연계
- 구조 연결은 구조 관계를 정의한다.구조 관계는 최소한 일정 시간 동안 시스템에 유지되는 연관성을 지정해야 한다.
- 절차 링크
- 절차적 연결은 절차적 관계를 정의한다.절차적 관계는 물체를 변환하는 공정의 시간 의존적 또는 조건부 트리거를 지정하여 기능 달성을 위해 시스템이 작동하는 방법을 명시해야 한다.
- 사건 및 조건
- Event-Condition-Action 패러다임은 OPM 운영 의미와 제어 흐름을 제공한다.이벤트는 객체가 생성되거나(혹은 시스템의 관점에서 생성되는 것으로 보인다) 객체가 지정된 상태로 들어가는 시점을 말한다.런타임에, 이 프로세스 트리거링은 프로세스 전제조건의 평가를 개시한다.따라서 프로세스 실행의 시작에는 (1) 트리거링 이벤트와 (2) 전제조건의 만족이라는 두 가지 전제조건이 있다.
이벤트가 프로세스를 트리거하면 이벤트는 더 이상 존재하지 않는다.
구문 및 의미론
형편
개체와 프로세스는 많은 점에서 대칭적이며, 집합, 일반화, 특성화 등 관계 측면에서 공통점이 많다.
OPM을 유용하게 적용하기 위해서는 성공적인 시스템 분석과 설계를 위한 전제조건으로 모델러가 대상과 프로세스를 필수적으로 구분해야 한다.기본적으로 명사는 대상을 식별해야 한다.
Thing 일반 속성
OPM 사물에는 다음과 같은 세 가지 일반적인 속성이 있다.
- 인내심
- 에센스
- 소속
OPM thing 일반 속성에는 다음과 같은 기본값이 있다.
- 어떤 사물의 제휴 일반적 속성의 기본값은 체계적이다.
- 시스템 에센스는 시스템의 기본 에센스가 되어야 한다.본질처럼, 그것의 가치는 비공식적이고 물리적이다.대다수의 사물이 비공식적인 정보시스템은 일차적으로 정보시스템이어야 하는 반면, 대다수의 사물이 물리적 시스템인 정보시스템은 일차적으로 물리적이어야 한다.
- 일차적으로 비공식적인 [물리적] 시스템에서 사물의 본질 일반적 속성의 기본값은 비공식적인 [물리적]이어야 한다.
객체 상태
- 상태 저장 및 상태 비저장 개체
- 도브 도리는 OPM 및 SysML과 함께 모델 기반 시스템 엔지니어링에서 "개체 상태는 개체가 존재할 수 있는 가능한 상황"이라고 설명한다.객체 상태는 그것이 속해 있는 객체의 맥락에서만 의미가 있다."상태 비저장 개체는 상태 사양이 없는 개체여야 한다.상태 저장 물체는 허용 가능한 상태 집합을 지정하는 물체여야 한다.런타임 모델에서 임의의 시점에서 상태 저장 객체 인스턴스는 특정 허용 상태에 있거나 두 상태 간에 전환 중에 있다.
- 속성 값
- 속성은 사물을 특징짓는 사물이다.속성 값은 값이 속성의 상태라는 의미에서 상태를 전문화하는 것이다: 개체는 다른 개체인 속성을 가지고 있는데, 이 속성은 그 속성을 나타내는 객체가 존재하는 동안 일정 기간 동안 그 값이 할당된다.
- 객체 상태 표현
- 상태는 소유물 내부에 위치한 둥근 코너 직사각형으로 그래픽으로 정의된다.그것은 물체 없이는 살 수 없다.OPL 텍스트에서 상태 이름은 대문자화 없이 굵은 글씨로 표시되어야 한다.
- 초기, 기본값 및 최종 상태
- 초기, 최종 및 기본 상태 표시
- 초기 상태는 두꺼운 윤곽선을 가진 상태 표현에 의해 그래픽으로 정의된다.최종 상태는 이중 윤곽선을 가진 상태 표현에 의해 그래픽으로 정의된다.디폴트 상태는 왼쪽에서 대각선으로 표시된 열린 화살표가 있는 상태 표현에 의해 그래픽으로 정의된다.해당 OPL 문장은 초기, 최종 또는 기본 상태에 대한 명시적 지표를 포함해야 한다.
링크
절차 연결
절차 연결은 다음 세 가지 유형 중 하나이다.
- 변환 링크, 변압기(프로세스에서 변환하는 객체) 또는 그 상태를 객체 변환을 모델링하는 프로세스, 즉 프로세스 실행의 결과로 해당 객체의 생성, 소비 또는 상태 변경과 연결한다.
- Enabler(프로세스 발생을 가능케 하지만 그 프로세스에 의해 변형되지 않는 개체) 또는 그 상태를 그 프로세스의 발생을 가능하게 하는 프로세스로 연결하는 활성화 링크.
- 제어 링크(컨트롤 링크)는 제어 수정자(사건의 경우) 또는 c(조건의 경우)와 같은 절차적(변환 또는 활성화) 링크로서 제어 요소의 의미론을 추가한다.문자 e는 링크된 프로세스를 실행하기 위한 이벤트를 의미하며, 문자 c는 호출 또는 예외를 나타내는 두 프로세스의 연결 또는 링크된 프로세스의 실행을 위한 조건을 의미한다.
- 절차 링크 고유성 OPM 원리
- 프로세스는 적어도 하나의 개체를 변환해야 한다.따라서 프로세스는 변환 링크를 통해 적어도 하나의 객체 또는 객체 상태에 연결되어야 한다.어떤 특정한 추상화 정도에서, 물체나 그 상태 중 하나는 그것이 연결하는 과정에 관하여 모델 요소로서 정확히 하나의 역할을 가져야 한다: 물체는 변환자 또는 활성화자일 수 있다.또한 이벤트(컨트롤 수식어 e가 있는 경우) 또는 조건화 객체(컨트롤 수식어 c가 있는 경우) 또는 둘 모두에 대한 트리거가 될 수 있다.
- 주 지정 절차 연결
- 주 지정 절차 연결은 프로세스를 개체에 연결하기 보다는 프로세스를 해당 개체의 특정 상태로 연결한다는 점에서 절차적 연결 상대방에 대한 상세 버전이다.
- 링크 변환
- 변환 링크의 세 가지 유형은 다음과 같다.
- 소비 링크: 그래픽으로 소모품에서 소비 과정으로 향하는 닫힌 화살표가 있는 화살표가 소비 링크를 정의한다.가정하면, 프로세스가 실행되기 시작하자마자 소비된 개체가 사라진다.소비 링크 OPL 문장의 구문은 다음과 같다: 처리는 소비자를 소비한다.
- 효과 링크: 연결된 프로세스가 연결된 개체에 영향을 미치고, 즉, 프로세스가 피영향자의 상태에 지정되지 않은 변경을 유발한다는 것을 지정하는 변환 링크.그래픽으로, 영향을 받는 프로세스와 영향을 받는 물체 사이의 각 방향을 가리키는 두 개의 닫힌 화살표가 있는 양방향 화살표는 효과 링크를 정의해야 한다.효과 링크 OPL 문장의 구문은 다음과 같다: 처리가 영향을 미친다.
- 결과 링크: 그래픽으로 작성 프로세스에서 결과자까지 가리키는 닫힌 화살표가 있는 화살표는 결과 링크를 정의해야 한다.결과 링크 OPL 문장의 구문은 다음과 같다: 처리 결과.
- 링크 사용
- 활성화 링크는 프로세스를 활성화하기 위해 존재해야 하는 개체인 프로세스를 위한 활성화 도구를 지정하는 절차적 연결이다. 그러나 프로세스가 완료된 후 해당 개체의 존재와 상태는 프로세스가 시작되기 직전과 동일하다.활성화 링크의 두 가지 종류:
- 에이전트 및 에이전트 링크: 지능적인 의사결정이 가능한 인간 또는 인간 집단으로, 실행 내내 프로세스를 활성화하거나 제어하기 위해 시스템과 상호 작용하여 프로세스를 가능하게 한다.그래픽적으로는 에이전트 개체에서 에이전트 링크를 사용할 수 있는 프로세스로 확장되는 터미널 끝의 채워진 원("검은 막대 사탕")이 있는 선이 표시된다.에이전트 링크 OPL 문장의 구문은 다음과 같다: 에이전트가 처리를 처리한다.
- 계측기 및 계측기 링크:계측기의 존재와 가용성 없이 시작하거나 실행될 수 없는 프로세스의 무생물 또는 비결정적 지원자.
- 상태별 변환 링크
- 주 지정 소비 링크:소모품의 특정 상태에서 발생하는 소비 링크, 즉 소모품이 연결된 프로세스에 의해 소비되려면 소모품이 그 상태에 있어야 함을 의미한다.그래픽으로, 특정 개체 상태에서 개체를 소비하는 프로세스를 가리키는 닫힌 화살표가 있는 화살표는 상태 지정 소비 링크를 정의한다.
- 주 지정 결과 링크: 결과자의 특정 상태에서 종료되는 결과 링크, 즉 결과자가 구성 시 해당 결과 상태에 있어야 함을 의미한다.그래픽으로 프로세스에서 특정 개체 상태로 향하는 닫힌 화살표가 있는 화살표는 상태 지정 결과 링크를 정의한다.구문 OPL 문장은 다음과 같다: 프로세스는 자격을 갖춘 상태 객체를 산출한다.
- 주 지정 효과 링크:
- 입력 및 출력 효과 링크- 입력 링크는 객체의 입력 상태에서 변환 프로세스로 연결되는 링크인 반면, 출력 링크는 변환 프로세스에서 객체의 출력 상태로 연결되는 링크인 것이다.
- 입력-출력 지정 효과 링크: 입력 링크는 피영향자의 특정 상태에서 발생하며 출력 링크는 그 프로세스에서 발생하여 동일한 피영향자의 출력 상태에서 종료되는 효과 링크의 한 쌍.그래픽으로, 피영향자의 입력 상태에서 영향을 받는 프로세스에 이르는 닫힌 화살표 헤드가 있는 화살표 쌍과 그 프로세스에서 피영향자 상태에 이르는 유사한 화살표가 입력-출력 지정 효과 링크를 정의한다.구문 OPL 문장은 다음과 같다: 프로세스는 객체를 입력-상태에서 출력-상태로 변경한다.
- 입력 지정 효과 링크: 입력 링크가 피영향자의 특정 상태에서 발생하며 출력 링크는 해당 프로세스에서 발생하여 특정 상태를 지정하지 않고 피영향자에서 종료되는 효과 링크 쌍.그래픽적으로는 피영향자의 특정 상태(입력 상태)에서 프로세스까지의 닫힌 화살표가 있는 화살표와 그 프로세스에서 피영향자와 유사한 화살표로 구성된 화살표 쌍이 입력 지정 효과 링크를 정의한다.구문 OPL 문장은 다음과 같다: 프로세스는 입력 상태에서 객체를 변경한다.
- 출력 지정 효과 링크: 입력(소스) 링크가 피영향자로부터 발생하며, 출력 링크는 프로세스에서 발생하여 동일한 피영향자의 출력(대상, 결과) 상태에서 종료되는 효과 링크 쌍.그래픽적으로는, 피영향자의 어떤 상태에서도 영향을 받는 프로세스에 도달하지 않고 피영향자의 닫힌 화살표가 있는 화살표로 구성된 쌍의 화살표가 출력 지정 효과 링크를 정의한다.
- 주가 지정한 활성화 링크
- 특정 적격 상태에서 출발하여 프로세스에서 종료한다. 즉, 링크가 시작된 상태에 객체가 존재하는 경우에만 프로세스가 발생할 수 있다는 것을 의미한다.
- 주 지정 에이전트 링크: 그래픽으로, 에이전트 개체의 적격 상태부터 주 지정 에이전트 링크를 정의하는 프로세스까지 확장되는 터미널 끝에 채워진 원("블랙 롤리팝")이 있는 라인.구문 OPL 문장은 다음과 같다: Qualified-State Agent 처리 처리.
- 상태 지정 계측기 링크:계측기의 특정 적격 상태에서 발생하는 계측기 링크.그래픽으로, 계기 객체의 적격 상태에서 그것이 가능하게 하는 과정까지 연장되는 터미널 끝의 빈 원("흰색 막대 사탕")이 있는 선은 주 지정 기기 링크를 정의한다.구문 OPL 문장은 다음과 같다: 프로세싱에는 적격 상태 계측기가 필요하다.
이벤트 조건-조치 제어
- 개체 세트 및 프로세스 사전 처리 전제 조건
- OPM 프로세스가 트리거된 후 실행을 시작하려면, 사전 처리 개체 집합이라고 하는 하나 이상의 소비, 일부 소비, 또는 영향을 미치는 개체 집합이 필요하다.인스턴스 수준 실행 시, 프로세스 P의 사전 프로세스 객체 집합에서 각 소비자는 B를 소비해야 하며, B를 소비하는 P의 최저 수준 하위 프로세스의 시작 부분에서 존재하기 위해 중지되어야 한다.프로세스 P의 사전 처리 객체 집합에서 영향을 받는 각 개체(상태 변화가 있는 개체) B는 P의 최저 수준 하위 프로세스의 시작 부분에서 입력 상태에서 벗어나야 한다.
- 사후 처리 객체 설정 및 사후 처리 조건
- 공정 후 객체 집합이라고 하는, 하나 이상의 결과, 일부 가능한 특정 상태 및/또는 영향을 포함하는 객체 집합은 프로세스를 실행하고 그 실행과 관련된 변환을 수행함으로써 발생한다.프로세스 P의 사후 프로세스 객체 집합에서 각 결과 B는 생성되어야 하며 B를 산출하는 P의 하위 프로세스 끝에 존재하기 시작해야 한다.프로세스 P의 사후 처리 객체 집합에서 영향을 받는 각 B는 P의 최저 수준 하위 프로세스가 끝날 때 출력 상태로 들어가야 한다.
제어 링크
이벤트 링크와 조건 링크는 각각 이벤트와 조건을 표현한다.제어 연결은 물체와 프로세스 또는 두 프로세스 사이에서 발생한다.
- 이벤트 링크
- 프로세스를 트리거하는 것은 프로세스를 실행하려는 시도를 시작하지만, 이 시도의 성공을 보장하지는 않는다.트리거링 이벤트는 만족을 위한 프로세스의 전제조건에 대한 평가를 강제하며, 만족을 위해 만족하는 경우에만 프로세스 실행을 진행하고 프로세스가 활성화될 수 있다.전제조건의 충족 여부를 떠나 행사가 무산된다.전제조건이 충족되지 않을 경우, 다른 이벤트가 프로세스를 활성화하고 성공적인 전제조건 평가를 통해 프로세스가 실행될 수 있을 때까지 프로세스 실행이 이루어지지 않는다.
- 기본 변환 이벤트 링크:소비 이벤트 링크는 개체와 프로세스 사이의 연결로, 개체의 인스턴스가 활성화된다.
- 소비 이벤트 링크: 그래픽으로, 작은 문자 e(이벤트용)로 개체에서 프로세스까지 가리키는 닫힌 화살표가 있는 화살표가 표시됨.소비 이벤트 링크 OPL 문장의 구문은 다음과 같다: Object 트리거 Process, 즉 Object를 소비한다.
- Effect event link: 그래픽으로, 개체와 프로세스 사이의 각 끝에서 닫힌 화살표가 있는 양방향 화살표 e(이벤트의 경우)효과 이벤트 링크 OPL 문장의 구문은 다음과 같다: Object 트리거 Process, 이것이 Object에 영향을 미친다.
- 기본 활성화 이벤트 링크:
- 에이전트 이벤트 링크:에이전트 이벤트 링크는 에이전트 개체에서 활성화 및 활성화하는 프로세스에 대한 사용 가능 링크입니다.그래픽으로, 에이전트 객체로부터 그것이 활성화되고 활성화되는 과정으로 확장되는 터미널 끝단에 채워진 원("검은 막대 사탕")이 있는 선은 (이벤트의 경우) 작은 문자로 활성화되고 활성화된다.에이전트 이벤트 링크 OPL 문장의 구문은 다음과 같다: 에이전트 트리거 및 처리 프로세스.
- 계기 이벤트 링크: 그래픽으로, 계기 물체에서 활성화되어 작은 문자 e(이벤트용)로 활성화되고 활성화되는 과정까지 연장되는 터미널 끝의 빈 원("흰색 막대사")이 있는 선입니다.기기 이벤트 링크 OPL 문장의 구문은 다음과 같다.계측기 트리거 프로세스, 계측기 필요
- 상태별 변환 이벤트 링크:
- 주 지정 소비 이벤트 링크: 주 지정 소비 이벤트 링크는 개체의 특정 상태에서 생성되어 프로세스에서 종료되는 소비 링크로서, 개체의 인스턴스가 활성화된다.그래픽으로, 닫힌 화살표가 있는 화살표가 객체 상태에서 작은 문자 e(이벤트용)로 프로세스를 가리킨다.주 지정 소비 이벤트 링크 OPL 문장의 구문은 다음과 같다: 지정된 상태의 개체 트리거 프로세스, 즉 개체를 소비한다.
- 입력-출력 지정 효과 이벤트 링크:입력-출력 지정 효과 이벤트 링크는 물체가 지정된 입력 상태로 들어갈 때 영향을 받는 프로세스를 활성화하는 추가적인 의미를 갖는 입력-출력 지정 효과 링크다.그래픽으로, 입력-출력 지정 효과는 작은 문자 e(이벤트용)와 연결된다.입력-출력 지정 효과 이벤트 링크 OPL 문장의 구문은 다음과 같다: 입력-상태 오브젝트 트리거 프로세스(Input-state Object 트리거 Process)는 객체를 입력-상태에서 출력-상태로 변경한다.
- 입력 지정 효과 이벤트 링크:입력 지정 효과 이벤트 링크는 개체가 지정된 입력 상태로 들어갈 때 영향을 받는 프로세스를 활성화한다는 추가적인 의미를 가진 입력 지정 효과 링크다.그래픽으로 입력 지정 효과는 작은 문자 e와 연결된다(이벤트용).입력 지정 효과 이벤트 링크 OPL 문장의 구문은 다음과 같다: 입력 상태 객체 트리거 프로세스 입력 상태로부터 객체를 변경한다.
- 출력 지정 효과 이벤트 링크:출력 지정 효과 이벤트 링크는 객체가 존재할 때 영향을 받는 프로세스를 활성화한다는 추가적인 의미를 갖는 출력 지정 효과 링크다.그래픽으로 출력 지정 효과 링크는 작은 문자 e(이벤트용)로 연결된다.출력 지정 효과 이벤트 링크 OPL 문장의 구문: Object in any state trigger Process(모든 상태의 개체 트리거 프로세스)로 Object를 대상 상태로 변경
- 상태 지정 에이전트 이벤트 링크:
- 상태 지정 에이전트 이벤트 링크: 상태 지정 에이전트 이벤트 링크는 에이전트가 지정된 상태로 들어갈 때 프로세스를 활성화한다는 추가적인 의미를 가진 상태 지정 에이전트 링크입니다.그래픽으로, 주 지정 에이전트는 작은 문자 e(이벤트용)로 연결된다.주 지정 에이전트 이벤트 링크 OPL 문장의 구문은 다음과 같다: 적격 상태 에이전트 트리거 및 처리".
- 주 지정 계측기 이벤트 링크: 주 지정 계측기 이벤트 링크는 계측기가 지정된 상태로 들어갈 때 프로세스를 활성화한다는 추가적인 의미를 갖는 주 지정 계측기 링크다.그래픽으로, 주 지정 계측기는 작은 문자 e(이벤트용)와 연결된다.주 지정 계기 이벤트 링크 OPL 문장의 구문은 다음과 같다: 적격 상태 계측기가 필요한 "적격 상태 계측기 트리거 처리".
- 호출 링크
- 프로세스 호출
- 자기소개 링크
- 암시적 호출 링크:암시적 호출은 확대된 프로세스의 맥락 안에서 하위 프로세스 종료 시 발생하며, 이때 하위 프로세스는 그 바로 아래의 프로세스를 호출한다.그래픽적으로, 호출되는 하위 프로세스와 호출되는 하위 프로세스 사이에는 아무런 연관성이 없다. 상위 프로세스의 확대/축소 컨텍스트 내에서 이들의 상대적 높이는 이러한 의미론을 내포한다.
- 조건 링크
- 조건 링크는 소스 객체 또는 객체 상태와 우회 메커니즘을 제공하는 대상 프로세스 사이의 절차적 링크다.
- 조건 소비 링크:조건 소비 링크는 개체에서 프로세스까지의 조건 링크로서, 런타임에 개체 인스턴스가 존재하면 프로세스 전제 조건이 충족되고 프로세스가 개체 인스턴스를 실행하고 소비한다는 것을 의미한다.그래픽으로, 화살촉 근처에 작은 글자 c(조건)가 있는 물체에서 공정으로 향하는 닫힌 화살표가 있는 화살표는 조건 소비 링크를 나타내야 한다.
- 조건 효과 링크:그러나 해당 객체 인스턴스가 존재하지 않는 경우 프로세스 전제조건 평가가 실패하고 컨트롤이 프로세스를 건너뛰게 된다.그래픽으로, 두 개의 닫힌 화살표가 있는 양방향 화살표는 영향을 받는 물체와 영향을 받는 프로세스 사이의 각 방향을 가리키며 화살표의 프로세스 끝 근처에 작은 글자 c(조건)를 나타낸다.
- 조건 에이전트 링크: 그래픽으로, 에이전트 개체에서 활성화된 프로세스까지 확장되는 터미널 끝의 채워진 원('검은 막대 사탕')이 있는 선으로, 프로세스 끝 근처에 작은 글자 c(조건의 경우)가 있다.조건 에이전트 링크 OPL 문장의 구문은 다음과 같다: 에이전트가 존재하는 경우 에이전트가 프로세스를 처리하고 그렇지 않으면 프로세스가 생략된다.
- 조건 계기 링크: 그래픽으로, 계기 물체에서 그것이 가능하게 하는 과정까지 연장된, 단자 끝에 빈 원("흰색 막대 사탕")이 있는 라인은, 프로세스 끝 가까이에 작은 글자 c(조건의 경우)가 있는 조건 계기 링크를 나타내야 한다.조건 계측기 링크 OPL 문장의 구문은 다음과 같아야 한다: 계측기가 존재하면 프로세스가 발생하며 그렇지 않으면 프로세스가 생략된다.
- 상태 지정 소비 링크:상태 지정 소비 링크는 특정 상태의 개체에서 발생하여 프로세스에서 종료되는 조건 소비 링크로서, 개체 인스턴스가 지정된 상태로 존재하고 프로세스 전제조건의 나머지 부분이 충족되면 프로세스가 개체 인스턴스를 실행하고 소비한다는 것을 의미한다.그래픽으로, 화살촉이 닫힌 화살표가 있는 화살표는 화살촉 근처에 작은 글자 c(조건의 경우)가 있는 프로세스를 가리킨다.
- 조건 입력-출력 지정 효과 링크:조건 입력-출력 지정 효과 링크는 런타임에 객체 인스턴스가 존재하고 그것이 프로세스 입력 상태(그리고 나머지 프로세스 전제조건이 충족된다고 가정할 경우), 프로세스가 실행되어 객체 인스턴스에 영향을 미친다는 추가적인 의미와 함께 입력-출력 지정 효과 링크다.그래픽으로, 조건 입력-출력 지정 효과는 입력의 화살촉 근처에 있는 작은 문자 c(조건의 경우)와 연결된다.조건 입력-출력 지정 효과 링크 OPL 문장의 구문은 다음과 같다: 객체가 입력-상태일 때 프로세스가 발생하며, 이 경우 프로세스가 입력-상태에서 출력-상태로 변경되고, 그렇지 않을 경우 프로세스를 건너뛰게 된다.
- 조건 입력 지정 효과 링크:조건 입력 지정 효과 링크는 런타임에 객체 인스턴스가 지정된 입력 상태에 존재하고 프로세스 전제조건의 나머지 부분이 충족되면 프로세스가 입력 상태에서 지정되지 않은 상태로 변경하여 객체 인스턴스에 영향을 미친다는 추가적인 의미를 가진 입력 지정 효과 링크다.d state그러나 입력 상태에 해당 객체 인스턴스가 존재하지 않으면 프로세스 전제조건 평가가 실패하고 컨트롤이 프로세스를 건너뛰게 된다.그래픽으로, 조건 입력 지정 효과 링크는 입력 링크의 화살표 헤드 근처에 있는 작은 문자 c(조건의 경우)와 연결된다.조건 입력 지정 효과 링크 OPL 문장의 구문은 다음과 같다: 객체가 입력 상태일 경우 프로세스가 입력 상태에서 객체를 변경하고 그렇지 않을 경우 프로세스를 건너뛰는 경우.
- 조건 출력 지정 효과 링크:조건 출력 지정 효과 링크는 런타임에 개체 인스턴스가 존재하고 프로세스 전제조건의 나머지 부분이 충족되면 프로세스가 실행되며 지정된 출력 상태로 변경하여 개체 인스턴스에 영향을 미친다는 추가적인 의미를 가진 출력 지정 효과 링크다.그러나 해당 객체 인스턴스가 존재하지 않는 경우 프로세스 전제조건 평가가 실패하고 컨트롤이 프로세스를 건너뛰게 된다.그래픽으로, 조건 출력 지정 효과 링크는 입력 링크의 화살표 헤드 근처에 있는 작은 문자 c(조건의 경우)와 연결된다.조건 출력 지정 효과 OPL 문장의 구문은 다음과 같다: 객체가 존재하면 프로세스가 발생하며, 이 경우 프로세스가 Object를 출력 상태로 변경하고, 그렇지 않으면 Process를 생략한다.
- 상태 지정 에이전트 링크:상태 지정 에이전트 링크 OPL 문장의 구문은 다음과 같다. 에이전트가 정규화 상태일 경우 에이전트가 프로세스를 처리하며 그렇지 않으면 프로세스를 건너뛰게 된다.
- 상태 지정 계측기 링크
자세한 정보와 예는 OPM 및 SysML이 있는 모델 기반 시스템 엔지니어링, 13장 "동적 시스템 측면"[4]에서 확인할 수 있다.
구조 링크
구조적 연결은 시스템에서 정적, 시간 독립적이고 오래 지속되는 관계를 명시한다.구조 연결은 두 개 이상의 물체 또는 두 개 이상의 공정을 연결하지만, 전시 특성 연결의 경우를 제외하고는 물체와 공정이 연결되지 않는다.
- 단방향 태그가 지정된 구조 링크
- 한 사물에서 다른 것까지의 관계의 성격에 관한 사용자 정의 의미론을 가지고 있다.그래픽으로, 화살촉이 열린 화살촉.태그가 지정된 구조 링크를 따라 모델러는 연결된 객체(또는 프로세스) 간의 구조 관계의 특성을 표현하고 구문이 따르는 OPL 문장에 배치될 때 의미가 있는 태그를 텍스트 구문의 형태로 기록해야 한다.
- 단방향 null 태그가 지정된 구조 링크
- 태그가 없는 단방향 태그 구조 링크.이 경우 기본 단방향 태그가 사용된다.모델러는 특정 시스템 또는 시스템 집합에 대한 기본 단방향 태그를 설정할 수 있는 옵션이 있다.기본값이 정의되지 않은 경우 기본 태그는 "reltends to"가 된다.
- 양방향 태그가 지정된 구조 링크
- 양쪽 방향의 태그가 의미 있고 서로 역행하는 것만이 아닐 때, 그것들은 하나의 양방향 태그 구조 링크의 양쪽에 있는 두 개의 태그로 기록될 수 있다.결과적으로 태그가 붙은 구조 링크의 구문은 두 개의 분리된 태그가 붙은 구조 링크 OPL 문장으로, 각 방향마다 하나씩이다.그래픽으로 링크 선의 양 끝에 있는 반대편에 작살 모양의 화살촉이 있는 선은 다음과 같다.
- 상호 태그가 지정된 구조 링크
- 하나의 태그로 양방향 태그가 지정된 구조 링크.어느 경우든 상호주의는 양방향 구조 링크의 태그가 그것의 전방과 후방 방향에 대해 동일한 의미론을 가지고 있음을 나타낸다.태그가 나타나지 않을 경우 기본 태그는 "관련됨"이어야 한다.태그가 하나만 있는 상호 태그 구조 링크의 구문은 다음과 같아야 한다: 소스와 목적지는 상호주의 태그.태그가 없는 상호 태그 구조 링크의 구문은 다음과 같다: 소스와 목적지는 관련이 있다.
- 기본 구조 관계
- OPM 사물들 사이에 가장 보편적인 구조적 관계는 시스템을 지정하고 이해하는 데 특히 중요하다.각각의 근본적 관계는 OPM 사물, 근원 사물, 또는 리피네이션 한 가지를 하나 이상의 OPM 사물, 목적지 사물 또는 사물의 집합체 또는 정제물로 정교하게 또는 정교하게 한다.
- 집계 참여 링크
- 리피네이터(전체)는 하나 이상의 다른 정제품인 부품을 통합한다.그래픽으로, 선으로 전체와 선으로 연결되는 정점과 반대 수평 베이스로 연결되는 부분이 있는 검은색 솔리드(충전된) 삼각형은 집합 참여 관계 링크를 나타내야 한다.
- 전시특성연계
- 사물은 다른 사물을 나타내거나 특징지어진다.전시 특성 관계는 전시자(전시 특성화 관계)를 하나 이상의 정제재로 결합하며, 이는 전시자를 그래프로 특징짓는 특징, 더 큰 빈 삼각형 내부의 더 작은 검은색 삼각형, 선으로 전시자와 연결되는 그 큰 삼각형의 꼭지점, 그리고 반대편에 연결되는 특징(h)을 식별해야 한다.오리존탈) 기반은 전시-특성화 관계 링크를 정의한다.
- 일반화-전문화 및 상속
- 이것들은 많은 수의 객체나 프로세스 클래스를 슈퍼클래스로 추상화하고, 슈퍼클래스의 속성을 하위 클래스에 할당하는 것을 제공하는 구조적 관계다.
- 일반화-전문화 링크
- 전문화를 통한 상속
- 차별적 속성을 통한 전문화 제한:상속된 속성의 가능한 값의 하위 집합은 전문화를 제한할 수 있다.
- 분류-제도 및 시스템 실행
- 분류-제도 링크: 소스 사물, 즉 객체 클래스 또는 프로세스 클래스는 하나 이상의 목적지 사물에 연결되며, 이는 소스 사물의 패턴의 중요한 인스턴스(instance of the source things) 즉, 패턴에 의해 지정된 특징들이 명시적 값을 획득한다.이 관계는 모델러에게 특징값의 제공에 의해 생성된 클래스와 그것의 인스턴스 사이의 관계를 표현하기 위한 명시적인 메커니즘을 제공한다.그래픽적으로, 한 선에 의해 클래스 사물에 연결되는 정점과 선에 의해 반대쪽 베이스에 연결되는 인스턴스 사물이 있는 다른 비어있는 큰 삼각형 안에 있는 작은 검은색 원은 분류-인스턴트 관계 링크를 정의한다.구문은 다음과 같다: 인스턴스-사물은 클래스-사물의 인스턴스다.
- 객체 클래스 및 프로세스 클래스의 인스턴스
- 주별 구조 관계 및 링크
- 주 지정 특성화 관계 및 링크:특수 목적물의 구별되는 속성에 대한 값을 나타내는 특수 목적물의 전시 특성 관계, 즉 특수 목적물은 그 값만 가져야 한다는 것을 의미한다.그래픽으로, 전시 특성 링크 삼각형 기호는 전문화된 물체에 연결되는 꼭지점과 그 반대되는 기초가 가치에 연결되는 것으로, 국가별 특성화 관계를 정의한다.구문은 다음과 같다: Specialized-object는 값 이름 속성 이름을 나타낸다.
- 주 지정 태그가 지정된 구조 관계 및 링크: 속성의 개체 또는 값 상태와 다른 개체 또는 상태 또는 값 사이의 구조적 관계, 즉 이 두 개 실체가 연관성의 의미론을 표현하는 태그와 연관되어 있음을 의미한다.null 태그(즉, 태그가 지정되지 않은 경우)의 경우 해당 기본 null 태그를 사용한다.주 지정 태그가 지정된 구조 관계의 세 가지 그룹은 (1) 소스 지정 태그가 지정된 구조 관계, (2) 대상 상태 지정 태그가 지정된 구조 관계, (3) 소스 및 대상 상태 지정 태그가 지정된 구조 관계가 있다.이러한 각 그룹은 적절한 단방향, 양방향 및 상호 태그가 지정된 구조 관계를 포함하며, 7가지 종류의 주 지정 태그가 지정된 구조 관계 링크와 해당 OPL 문장을 제공한다.
자세한 정보와 예는 OPM 및 SysML이 있는 모델 기반 시스템 엔지니어링 3.3장 "구조 링크 추가"[4]에서 확인할 수 있다.
관계기초
- 구조 및 절차적 연결의 객체 다중성
객체 다중성은 링크와 관련된 객체 인스턴스의 수량 또는 개수에 대한 요구사항 또는 제약조건 사양을 참조해야 한다.다중성 규격이 존재하지 않는 한 링크의 각 끝은 하나의 인스턴스만 지정해야 한다.다중성을 가진 객체를 포함하는 OPL 문장의 구문에는 객체 이름 앞에 있는 객체 다중성이 포함되어야 하며, 객체 이름은 복수 형태로 표시되어야 한다.다중성 사양은 다음과 같은 경우에 나타날 수 있다.
- 모든 종류의 태그가 지정된 구조 링크에 대해 여러 소스 또는 대상 객체 인스턴스를 지정한다.
- 통합-통합 링크에서 여러 인스턴스가 있는 참가자 객체를 지정한다. 여기에는 전체 부분의 각 부분에 다른 참여 사양이 첨부될 수 있다.
- 절차적 관계에서 여러 인스턴스가 있는 객체를 지정한다.
- 개체 다중성 표현식 및 제약 조건
객체 다중성은 연산자 기호 "+", "–", "*", "/", "(", ")"를 통상적인 의미와 함께 사용해야 하며 해당 OPL 문장에서 일반적인 텍스트 서신을 사용해야 한다.
정수 또는 산술적 표현은 객체 다중성을 구속할 수 있다.그래픽으로 표현 제약조건은 그들이 구속하는 표현으로부터 분리되는 세미콜론 뒤에 나타나야 하며, 세트 멤버를 둘러싸는 경우 등/부호 기호 "=", "<", "=", "=", "=", "}", 그리고 멤버쉽 운영자 "in" (초, ∈)를 사용해야 하며, 모두 통상적인 의미와 함께 사용해야 한다.해당 OPL 문장은 구속조건이 적용되는 대상의 뒤에 굵은 글씨로 구속조건 구문을 "제약을 받는 경우" 형식으로 배치해야 한다.
- 속성 값 및 다중성 제약 조건
구조 및 절차적 링크에 대한 객체 다중성의 표현은 정수 값으로 분해되는 정수 값 또는 매개변수 기호를 지정한다.대조적으로, 객체나 프로세스의 속성과 관련된 값은 정수 또는 실제 값, 또는 정수 또는 실제 값으로 분해되는 매개변수 기호일 수 있으며, 문자열과 열거된 값일 수도 있다.그래픽으로, 라벨이 부착된 둥근 코너 직사각형은 라벨 이름에 해당하는 값 또는 값 범위(정수, 실수 또는 문자열 문자)를 가진 속성 값을 나타내야 한다.OPL 텍스트에서 속성 값은 대문자화 없이 굵게 나타나야 한다.
속성 값 OPL 문장이 있는 객체의 구문은 다음과 같아야 한다: 객체의 속성은 값이다.
속성 값 범위 OPL 문장이 있는 객체의 구문은 다음과 같아야 한다: 객체 범위의 속성은 값 범위다.실제 숫자 값을 갖는 속성과 연결하는 구조 또는 절차적 링크는 관계 제약조건을 지정할 수 있으며, 이는 객체 다중성과 구별된다.
그래픽적으로 속성 값 제약조건은 링크의 속성 끝 가까이에 있는 숫자, 정수 또는 실제에 의한 주석 또는 기호 매개변수를 나타내며 링크와 정렬한다.
논리 연산자: AND, XOR 및 OR
- 논리적 AND 절차 연결
절차적 관계 중 논리 연산자 AND, XOR 및 OR은 정교한 프로세스 전제 조건과 사후 조건의 명세를 가능하게 한다.별도의 비터치 링크는 논리적 AND의 의미론을 가져야 한다.
여기서 금고를 열려면 세 개의 열쇠가 모두 필요하다.
- 논리적 XOR 및 OR 절차 링크
링크 팬은 XOR 또는 OR 운영자의 의미론을 따라야 한다.링크에 공통적인 링크 팬 엔드는 수렴 링크 엔드가 되어야 한다.링크에 공통적이지 않은 링크 끝은 다이버전트 링크 끝이어야 한다.
XOR 운영자는 다이버전트 링크 엔드에 물체가 있거나 다이버전트 링크 엔드에 프로세스가 있는 경우 링크 팬의 범위에 있는 것 중 정확히 한 가지가 존재함을 의미해야 한다.그래픽상, 수렴 엔드 포인트의 아크 초점과 링크 팬의 링크를 가로지르는 점선은 XOR 운영자를 나타내야 한다.
수술실 운영자는 연결 팬의 범위에 있는 둘 이상의 것 중 하나 이상이 존재한다는 것을 의미하며, 서로 다른 연결 엔드에 프로세스가 있는 경우 서로 다른 링크 엔드에 있는 물체가 있는 경우 또는 발생하는 것을 의미한다.그래픽상, 수렴 종단점의 초점과 링크에 걸쳐 있는 두 개의 동심 파선 호는 수술실 운영자를 나타내야 한다.
- 주 지정 XOR 및 OR 링크 팬
- 제어 수정 링크 팬
- 링크 확률 및 확률론적 링크 팬
- 실행 경로 및 경로 레이블
- 경로 라벨은 절차적 링크를 따른 라벨로, 프로세스 종료 시 따라야 할 옵션이 둘 이상 있는 경우, 우리가 프로세스에 들어간 것과 동일한 라벨을 가진 링크가 뒤따를 것이라고 규정한다.
모델링 원리 및 모델 이해
경계, 이해관계자 및 전제조건의 관점에서 시스템 목적, 범위 및 기능의 정의는 모델에 다른 요소가 나타나야 하는지를 판단하는 기초가 된다.이것은 시스템 모델의 범위를 결정한다.OPM은 모델 명료성과 완전성의 표현을 관리하기 위한 추상화 및 정제 메커니즘을 제공한다.[1][4]
- 이해관계자 및 시스템의 수익자 식별
인공 시스템의 경우, 이 기능은 개인이나 그룹의 사람들, 즉 수혜자에게 이익이 될 것으로 예상된다.시스템의 기능이 주요 수혜자의 기능적 가치 기대치에 부합한 후, 모델러는 OPM 모델에 다른 주요 이해당사자를 식별하여 추가한다.
- 시스템 다이어그램
결과적인 최상위 OPD는 이해관계자 그룹, 특히 수혜자 그룹을 포함하는 시스템 다이어그램(SD)과 추가적인 최상위 환경 사물이 시스템 운용의 맥락을 제공하는 것이다.SD는 시스템의 기능과 맥락을 이해하는 데 필수적인 것, 즉 중심적이고 중요한 것만을 포함해야 한다.함수는 SD의 주요 프로세스로서, 또한 이 프로세스와 관련된 대상들, 즉 수혜자, 피연산자(프로세스가 작동하는 개체), 그리고 아마도 공정이 변화하는 피연산자의 속성도 포함한다.SD는 또한 기능을 활성화하는 시스템을 나타내는 물체를 포함해야 한다.이 시스템의 기본 이름은 함수 이름에 "시스템"이라는 단어를 추가하여 만들어진다.예를 들어, 기능이 카페인팅이라면, 시스템의 이름은 카페인팅 시스템일 것이다.
- OPD 트리
- 명확성과 완전성 절충
적절한 균형을 잡으려면 모델 개발 중에 컨텍스트를 세심하게 관리해야 한다.그러나 모델러는 OPM 시스템 모델의 전체 OPD 세트에 의해 제공되는 정보의 결합을 이용할 수 있으며 명확하고 명확하지만 완전하지는 않은 OPD와 세부사항을 추가함으로써 시스템의 일부 작은 부분에 대한 완전성에 초점을 맞춘 OPD를 가질 수 있다.
- 미세-압축 메커니즘
OPM은 모델 명확성과 완전성의 표현을 관리하기 위한 추상화 및 정제 메커니즘을 제공해야 한다.이러한 메커니즘은 시스템 및 시스템을 구성하는 것들을 그들 사이에 공통적인 대상, 프로세스 및 관계에 의해 상호 관련되는 다양한 맥락에서 제시하고 볼 수 있어야 한다.
- 상태 표현식 및 상태 억제
상태 억제의 역방향은 상태 표현이어야 한다. 즉, 가능한 개체 상태에 관한 정보를 추가하여 OPD를 개선해야 한다.OPD에 해당하는 OPL은 표시된 물체의 상태만 표시해야 한다.
- 펼치기 및 접기
그것은 펼쳐지는 것 아래에 계층적으로 있는 일련의 것들을 드러낸다.결과는 계층 트리로, 그 뿌리는 펼쳐진 것이다.뿌리와 연결된 것은 펼쳐진 사물의 맥락을 이루는 것이다.반대로 접기는 추상화 또는 구성의 메커니즘으로, 펼쳐지는 계층적 트리에 적용된다.
- 확대/축소 및 축소
In-Zooming은 일종의 전개로, 집합 참여에만 적용 가능하며 추가적인 의미론도 있다.프로세스의 경우, 확대/축소 기능을 통해 하위 프로세스, 시간 순서, 객체와의 상호작용 및 이 컨텍스트에 대한 제어 전달을 모델링할 수 있다.객체의 경우, 확대/축소 기능은 구성 객체의 공간적 또는 논리적 순서를 모델링할 수 있는 고유한 컨텍스트를 생성한다.그래픽적으로 확대된 프로세스의 컨텍스트 내의 타임라인은 프로세스 타원 기호의 맨 위에서 타원 바닥으로 흐른다.
메타모델링
- OPM 모델 구조
- OPD 시공 모델과 기본 시공
OPD 메타모델의 이미지에서 볼 수 있는 모델은 OPD Construction 개념을 정교하게 설명한다.이 모델의 목적은 Basic Construct와 다른 가능한 OPD Construct를 구별하는 것이다.A Basic Construct는 OPD Construct의 전문화로서, 정확히 하나의 Link로 연결된 두 가지 사물로 구성된다.비 기본 구조는 무엇보다도 링크 팬이 있거나 세 개 이상의 정밀한 구조를 포함한다.
모델러는 Thing Set의 연결이 끊기고 연결된 상태를 추가함으로써 모델에 프로세스를 추가할 수 있다.따라서 모델의 목적에는 링크 세트를 연결 도구로 사용하여 분리된 사물 세트를 연결된 사물 세트로 변환하는 작용이 포함된다.
- OPM 사물 모형
사물의 OPM 모델은 OPM 사물의 모델로서, 아래의 사물의 모델 이미지에서와 같이 오브젝트와 프로세스로의 전문화를 보여준다.상태 집합은 비어 있을 수 있는 개체, 상태 비저장 개체 또는 상태 저장 개체의 경우 비어 있지 않은 개체의 특성을 나타낸다.
상태를 가진 상태 저장 개체는 상태 비저장 상태별 개체 세트를 각 주마다 하나씩 생성한다.특정 상태별 개체는 특정 상태의 개체를 가리킨다.상태별 개체의 개념을 개체와 상태 둘 다로 모델링하면 단순히 개체를 지정함으로써 개체와 그 하나 또는 그 상태를 언급함으로써 개념 모델을 단순화할 수 있다.
- 사물 일반적 특성의 OPM 모델
사물 일반적 속성의 OPM 모델은 전시 특성 링크의 속성 정련으로 모델링된 사물 및 그것의 페르세우스, 에센스 및 제휴 일반 속성을 묘사한다.인내심은 개체와 프로세스 사이의 구별되는 속성이다.
- 확대/축소 및 축소 모델
새로운 다이어그램의 확대/축소 및 확장 축소 모두 기존 OPD 컨텍스트에서 새로운 OPD 컨텍스트를 생성한다.뉴 다이어그램 인 줌잉은 상대적으로 디테일이 적은 OPD로 시작하며, 디테일이 덜한 OPD의 특정한 것에 적용되는 후예 OPD로서 정교함이나 정교함을 더한다.
버전
- OPM
OPM의 현재 버전은 자동화 시스템 및 통합 - 객체-프로세스 방법론에 명시된 ISO/PAS 19450:2015이다.[1]도리의 2016년 책에 수록된 명세서는 ISO/PAS 19450:2015의 상위 집합이다.[4]
OPM의 이전 버전은 도리의 2002년 책에 명시되어 있다.[3]
- OPCAT
현재 OPCAT 버전은 4.1이다.테크니온의 기업 시스템 모델링 실험실에서 무료로 이용할 수 있다.[5]
기능이 적은 이전 OPCAT 버전 3.1도 같은 사이트에서 구입할 수 있다.둘 다 자바어로 코딩되어 있다.최초의 OPCAT 버전인 OPCAT 1.X는 1998년에 Visual C++로 작성되었다.
2016년 초, 도리의 관리 하에 있는 학생들로 구성된 팀이 OPCloud라고 불릴 새로운 세대의 OPCAT를 연구하기 시작했다.[13]소프트웨어 이름으로 제안된 대로 클라우드 기반 애플리케이션으로, 웹 기반 애플리케이션을 이용한 OPM 모델을 사용자가 만들 수 있게 된다.[14]
표준화
ISO(International Organization for Standardization)는 162개 국가 표준 기구의 회원으로 구성된 독립된 비정부 국제 기구로서 혁신을 지원하고 글로벌 과제에 대한 해결책을 제공하는 자발적이고 합의된 시장 관련 국제 표준을 개발한다.이 표준은 품질, 안전성 및 효율성을 보장하기 위해 제품, 서비스 및 시스템에 대한 세계적 수준의 규격을 제공한다.
ISO 및 OPM
2008년 6월 리차드 마틴은 네덜란드 위트레흐트에서 열린 INCOSE 국제 심포지엄에서 프레젠테이션을 마친 뒤 도브 도리에게 접근해 OPM 국제표준 작성 가능성을 문의했다.[citation needed]자동화 시스템 상호운용성 아키텍처와 모델링을 위한 ISO TC184/SC5/WG1의 소집자인 Martin은 한동안 정적 정보와 프로세스 모델링 이상을 제공하는 방법론을 찾고 있었다.[citation needed]그는 도리에게 OPM의 모델링 능력과 동적 시뮬레이션 기회를 모두 보여줄 수 있는 간단한 모델을 제시하였다.[citation needed]
2010년 5월, 도리는 ISO 기술 위원회 184/소위원회 5 (TC184/SC5) 전체회의에서 OPM과 그의 시범 모델에 대한 간략한 개요를 제시하였고, 이후 SC5가 만든 표준을 개선하기 위한 OPM의 가능성을 검토하기 위한 목적으로 OPM 연구그룹을 만들자는 결의안을 채택하였다.[15]
OPM Study Group은 2010년 10월에 작업을 시작하여 2011년 SC5 Bonal에 대한 중간 보고서를 발표했다.[16]보고서는 기존 SC5 표준을 모델링하기 위해 OPM을 여러 번 사용하는 것을 포함하였고, 텍스트 기반인 ISO 표준이 불일치와 불완전한 정보로 인해 어려움을 겪기 쉽다는 인식으로 OPM 표준화를 위한 초기 동기를 이끌어냈다.표준이 텍스트 기반이 아닌 모델 기반이라면 이러한 결여는 크게 감소할 수 있으며, OPM은 이러한 목적을 위해 유용한 기초 모델링 패러다임을 제공했다.
최종 OPM 연구 그룹 보고서와 모델 기반 표준 작성 문서를 위한 메타모델 초안이 2012 SC5 본회의에서 전달되었다.[17]OPM Study Group의 노력이 진행됨에 따라 OPM이 MBSE(모델 기반 시스템 엔지니어링)와 자연 및 인공 시스템 모두를 모델링하는 견고하고 포괄적인 기반으로서의 역할도 할 수 있다는 것이 명백해졌다.[citation needed]
ISO 19450 문서
TC184/SC5/WG1 참가자는 2011년 9월에 OPM PAS의 초안을 16페이지, 2개의 부속문서, 총 25페이지에 달하는 참고 문헌을 받았다.[citation needed]대부분의 콘텐츠는 단순히 하위조항 제목과 공간 보유자 그래픽을 식별했다.[citation needed]2012년 SC5 전체회의까지, PAS 초안에는 OPM 기능을 기술하는 10개의 전체 조항과 총 86페이지에 달하는 6개의 부속서가 포함되었다.[citation needed]한 부속문서는 OPL을 위한 EBNF(Extended Backus-Naur Form, 컨텍스트 자유언어를 공식적으로 지정하여 프로그래밍 언어의 구문을 가능하게 하는 데 사용) 규격과 또 다른 상세한 OPD 그래프 문법이었다.EBNF 규격의 검증을 용이하게 하기 위해, 데이비드 쇼터는 EBNF 문장의 일관성과 완전성을 평가하는 스크립트를 작성했다.[citation needed]의미 있는 예를 추가하고 식별된 모든 섹션을 완성하기 위한 추가적인 노력은 2013년 SC5 총회 때까지 138페이지의 초안을 작성했다.[citation needed]그 후, 작업 초안은 SC5 회원에게 최초 배포하기 위한 위원회 초안으로 SC5 사무국에 등록되었다.[citation needed]
OPM 규격을 요구하는 SC5 결의안에는 문서가 PAS(Public Available Specification, PAS)로 등록되어야 한다고 명시되어 있었기 때문에, 승인 투표 기회가 단 한 번뿐일 것이다.2014년 4월, SC5에 ISO/PAS 19450에 대한 새로운 작업 항목 제안 및 개정 위원회 초안을 전달하여 검토하였다.[citation needed]지금까지 위원회 초안은 98페이지에 앞부분을 더하고, 4개의 별관과 30개의 참고 문헌으로 총 183페이지가 되었다.[citation needed]ISO는 2015년 3월 ISO/PAS 19450에 대한 투표 결과를 8 승인, 1 코멘트로 승인, 1 기권으로 등록했다.[citation needed]
ISO/PAS 19450은 2015년 12월 15일 ISO에 의해 총 162페이지로 공식 발행되었으며, 그래픽과 텍스트 표현을 자동화된 모델 동작 시뮬레이션에 적합한 단일 패러다임으로 결합하는 모델링에 대한 새로운 접근방법에 대한 공식 사양을 표준화 커뮤니티에 제공하기 위한 6년간의 노력을 마무리했다.이오르
OPM 대 SysML 및 UML
- OPM 대 SysML
SysML은 UML의 프로파일 메커니즘을 사용하여 UML(Unified Modeling Language)의 확장으로 정의된다.[11]
- OPM 대 UML
OPM과 UML의 차이는 분석 및 설계 단계에서 인지도가 높다.UML이 멀티 모델인 반면 OPM은 단일 통일 구조-행동 모델을 지원한다.중요한 차이점은 13개의 다이어그램 유형에 걸쳐 행동이 확산되는 UML의 구조 지향 접근법에서 비롯되는데, 이는 필연적으로 모델 다중성 문제를 유발한다.[18]첫째, OPM 접근방식을 사용하면 주 도표(SD)에서 주요 프로세스, 객체 및 이들 프로세스 간의 연결을 볼 수 있다.[3][page needed]또 주계통의 이익(SD에 표시)이 무엇인지 쉽게 이해할 수 있다.OPM에서는 또한 동작, 구조, 기능성의 세 가지 주요 측면을 이해하는 것이 더 쉽다. (다른 유형의 다이어그램으로 이러한 측면을 설명하는 UML과 비교된다.)[3][page needed]데이터베이스 전개 모델링은 시스템에 저장된 시스템과 모든 세부사항을 이해하는 데 기여한다.또한, 확대/축소 기능을 생성하면 모델을 단순화할 수 있다.OPM은 시스템이 경로를 절약하고 결정을 내리는 방법과 같은 체계적인 프로세스에 대한 광범위한 지식을 필요로 한다.
OPM 모델에서 SysML 뷰 생성
두 언어는 범용 시스템 엔지니어링을 위한 수단을 제공하는 동일한 목적을 지향하지만, 이러한 언어들은 이 목표를 실현하는데 있어서 다른 접근방식을 취한다.SysML은 UML(Unified Modeling Language)의 프로파일이다.
OPM-to SysML 번역은 단일 OPM 요소(엔티 또는 링크)가 보통 다른 SysML 다이어그램 유형에 속하는 여러 SysML 요소를 번역한다는 점에서 일대다.예를 들어 OPM 프로세스는 객체를 변환(생성, 소비 또는 상태 변경)하는 실체로 정의되며, 다음과 같은 SysML 실체의 하위 집합에 매핑될 수 있다.
- 사용 사례(사용 사례 다이어그램에서)
- 작업(활동 다이어그램)
- 상태 전환 트리거(상태 시스템 다이어그램)
OPM과 SysML은 서로 구별되고 다르게 설계된 두 개의 언어인 만큼, 한 언어의 모든 구성품이 다른 언어의 동일한 구성을 가지는 것은 아니다.
- OPM 다이어그램에서 생성할 수 있는 UML의 첫 번째 유형의 다이어그램은 시스템의 사용을 모델링하기 위한 Use Case Diagraphy이다.Use Case Diagram을 구성하는 주요 요소는 행위자 및 사용 사례(주체)와 그들 사이의 관계(링크)이다.따라서 OPM에서 Use Case Diagram의 생성은 환경 객체(수행자)와 그것과 연결된 프로세스(사용 사례)에 기초한다.그림 1은 SD0의 Use Case Diagraphy 생성 예시 입니다.그림에는 루트 OPM 다이어그램(a), 해당 OPL 텍스트(b), 생성된 Use Case 다이어그램(c)이 표시된다.그림 2는 동일한 OPM 모델(a)의 SD1 레벨 OPD와 생성된 Use Case Diagraphy(b)를 보여준다.
- 두 번째 유형의 다이어그램은 블록의 특징(특성과 운영 등)과 연관성, 일반화 등 블록 간 관계를 정의하는 블록 정의 다이어그램(BDD)이다.BDD 생성은 OPM 모델의 체계적 객체 및 그 관계, 주로 다른 모델 요소와의 구조적 관계에 기초한다.
- 세 번째 유형의 다이어그램은 흐름을 지정하기 위한 활동 다이어그램이다.활동 다이어그램에 포함된 주요 구성 요소는 작업 및 라우팅 흐름 요소들이다.우리의 맥락에서, 하위 프로세스, 즉 OPM 모델에 확대축소된 프로세스를 포함하는 각 OPM 프로세스에 대해 별도의 활동 다이어그램을 생성할 수 있다.설정 대화상자를 통해 지정할 수 있는 두 가지 종류의 사용자 매개변수가 있다.첫 번째 방법은 OPM 프로세스 선택을 다룬다.한 가지 옵션은 목록에서 선택하여 필요한 OPM 프로세스를 명시적으로 지정하는 것이다.기본 옵션인 대안은 루트 OPD(SD)로 시작해 계층 아래로 내려가는 것이다.여기서 두 번째 파라미터(첫 번째 파라미터와 독립된 파라미터)에 도달하는데, 이는 계층 아래로 내려가는데 필요한 OPD 레벨(k)의 수입니다.추상화 수준에 대한 사용자 제어권을 부여하기 위해, 도표는 계층 아래로 k 레벨까지 생성된다.각 레벨은 추가 활동 다이어그램이 생성되는데, 이 다이어그램은 상위 레벨 활동을 둘러싸는 곳에 포함된 하위 활동(하위 다이어그램)이다.이 옵션의 기본 설정은 "모든 수준 하향"(예: "k = ∞")[19]이다.
참고 항목
참조
- ^ a b c d e "ISO/PAS 19450:2015 - Automation systems and integration -- Object-Process Methodology". iso.org. December 2015. Retrieved 3 May 2017.
- ^ a b Dori, Dov (1995). "Object-Process Analysis: Maintaining the Balance between System Structure and Behavior". Journal of Logic and Computation. 5 (2): 227–249. doi:10.1093/logcom/5.2.227.
- ^ a b c d e Dori, Dov (2002). Object-Process Methodology: A Holistic Systems Paradigm. Berlin, Heidelberg, New York: Springer-Verlag. doi:10.1007/978-3-642-56209-9. ISBN 978-3540654711. S2CID 13600128.
- ^ a b c d e f g h i j Dori, Dov (2016). Model-Based Systems Engineering with OPM and SysML. New York: Springer-Verlag. doi:10.1007/978-1-4939-3295-5. ISBN 9781493932955. OCLC 959032986. S2CID 32425215.
- ^ a b c "Enterprise Systems Modeling Laboratory » OPCAT installation". technion.ac.il. Retrieved 3 May 2017.
- ^ Booch, G. "방법전쟁에서 휴전이 필요한 때"1993년 7월/8월 객체 지향 프로그래밍 저널
- ^ Perelman, Valeria; Somekh, Judith; Dori, Dov (2011). Model verification framework with application to molecular biology. TMS-Devs '11. Society for Computer Simulation International. pp. 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 Model Lifecycle Management for MBSE". INCOSE International Symposium. 24: 207–229. doi:10.1002/j.2334-5837.2014.tb03145.x.
- ^ 참고 항목:Herre, 하인리히, 헬러, 바바라, Burek, Patryk을 말한다.Hoehndorf, 로버트, Loebe, 프랭크, Michalek, 한네스(2006년 7월)."일반 공식적인 존재론(GFO):근본적 존재론에 있는 물체와 프로세스 통합:제 파트:기본 원칙"(PDF).Onto-Med 리포트입니다.통일 모델링 언어처럼 개념적 모델링에 사용 중 8:3. 현재 언어(UML), 데이터베이스 분야에서 entity–relationship 모델링, 또는 Object-Process 방법론 그들의 존재론에 대한 약속에 따라 검사를 받을 수 있다.
- ^ Dori, Dov; Linchevski, Chen; Manor, Raanan (2010). "OPCAT – A Software Environment for Object-Process Methodology Based Conceptual Modelling of Complex Systems". Proc. 1st International Conference on Modelling and Management of Engineering Processes. University of Cambridge, Cambridge, UK, Heisig, P., Clarkson, J., and Vajna, S. (Eds.): 147–151.
- ^ a b Grobshtein, Yariv; Perelman, Valeriya; Safra, Eliyahu; Dori, Dov (2007). Systems Modeling Languages: OPM Versus SysML. Haifa, Israel: IEEE. pp. 102–109. ISBN 978-1-4244-0770-5. Retrieved 15 November 2018.
- ^ 참고 항목:
- ^ Enterprise Systems Modeling Laboratory. "opcloud".
- ^ Dori, Dov; Jbara, Ahmad; Levi, Natali; Wengrowicz, Niva. "Object-Process Methodology, OPM ISO 19450 – OPCloud and the Evolution of OPM Modeling Tools". Project Performance International. Retrieved 18 November 2018.
- ^ Dori, Dov; Howes, David; Blekhman, Alex; Martin, Richard. "OPM as a Basis for Model - Based Enterprise Standards, Report of the ISO TC184/SC5 OPM Working Group to the Plenary ISO TC184/SC5Meeting, Tokyo 26, 2010" (PDF). Retrieved 18 November 2018.
- ^ Blekhman, Alex; Dori, Dov; Martin, Richard. "Model-Based Standards Authoring" (PDF). Retrieved 18 November 2018.
- ^ SC 5 PLENARY MEETING. "Meeting Report" (PDF). Retrieved 18 November 2018.
- ^ Peleg, M.; Dori, D. (2000). "The Model Multiplicity Problem: Experimenting with Real-Time Specification Methods". 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). Creating SysML views from an OPM model. Haifa, Israel: IEEE. pp. 36–44. doi:10.1109/MBSE.2009.5031718. ISBN 978-1-4244-2967-7. S2CID 6195904.
외부 링크
![]() | Wikimedia Commons에는 Object Process Methodology와 관련된 미디어가 있다. |
- Dov Dori, 2003년 프레젠테이션, 객체-프로세스 방법론과 시각적 의미 웹으로의 적용
- Nava-Naya의 기술 언어의 특징
- 엔지니어 및 과학자에게 혜택을 주기 위한 개념 모델링 사고 프로세스 공식화, Dov Dori, 2015년 발표.
- 엔지니어 및 과학자에게 도움이 되는 개념 모델링 사고 프로세스 공식화
- OPD 변환에 대한 미국 특허 US7099809B2