shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
당대의 고명한 선승(禪僧) 무소 소세키에 따르면, 요리토는 주위에서 그 군사적 재능을 인정받고 있었고, 처형되기 직전까지도 요리토의 목숨을 구명해 줄 것을 호소하는 탄원의 목소리가 계속해서 오르고 있었다고 한다.
실제로 9월에 벌어진 사건임에도 석 달 동안이나 처벌이 지연된 것은 그런 분위기를 뒷받침한다는 견해가 있다. 요리토가 세운 그 숱한 전공들이 바쿠후의 존속에 보탬이 되었음을 인정받고 있었기에, 본래라면 요리토의 행위로 인해 아예 단절당했어도 이상할 것이 없었던 도키 집안은 존속을 허락받았고 가독은 조카 요리야스에게 이어지게 되었다는 것이다.
요리토의 자식들은 미쓰아키라(光明) 등 아홉 명이 있었는데, 각각을 시조로 하는 집안들이 있어 모토스 군(本巣郡) · 야마가타 군(山県郡) · 후와 군(不破郡)으로 옮겨가서 그곳에 토착했다고 전해진다.
무장으로서의 활약이 많지만 문화인으로서의 측면도 있어, 《신센자이와카슈》(新千載和歌集)・《신슈이와카슈》(新拾遺和歌集)・《신고슈이와카슈》(新後拾遺和歌集)에 요리토가 읊었다는 와카가 실려 있다. 또 아버지 요리사다와 함께 사찰을 세우고자 발원하면서 무소 소세키를 미노로 초청하여 가모 군(加茂郡)에 묘라쿠지(妙楽寺) · 도코지(東光寺)를 창건했다.
법명은 승선사각연대오대거사(乗船寺覚然大悟大居士). 일본 기후 현 기후 시의 데지카라오 신사(手力雄神社)에 있는 보협인탑(宝篋印塔)이 도키 요리토의 무덤이라 알려져 있다.
시스템 공학, 소프트웨어 공학 및 컴퓨터 과학 분야에서 기능 모델(Function model)은 모델링된 시스템 또는 주제 영역 내의 기능(활동, 작업, 프로세스, 운영)을 구조적으로 표현한 것이다.
기능 모델은 활동 모델 또는 프로세스 모델과 유사하게 정의된 범위 내에서 사업의 기능을 그래픽으로 표현한 것이다. 기능 모델의 목적은 기능 및 프로세스를 설명하고, 정보 요구 사항 발견을 돕고, 기회를 식별하며, 제품 및 서비스 비용을 결정하는 기초를 마련하는 것이다.
시스템 공학 및 소프트웨어 공학 분야의 기능 모델은 1950년대와 1960년대에 시작되었지만, 조직 활동의 기능 모델링의 기원은 19세기 후반으로 거슬러 올라간다.
19세기 후반에는 비즈니스 활동, 작업, 프로세스 또는 운영을 그림으로 나타내는 최초의 다이어그램이 등장했으며, 20세기 전반에는 비즈니스 프로세스 활동을 문서화하는 최초의 구조화된 방법이 등장했다. 이러한 방법 중 하나는 1921년 프랭크 길브레스가 "프로세스 차트—가장 좋은 방법을 찾는 첫 단계"라는 제목의 발표를 통해 미국 기계 기술자 협회 (ASME) 회원들에게 소개한 흐름 프로세스 차트였다. 길브레스의 도구는 빠르게 산업공학 교육 과정에 도입되었다.
시스템 공학 분야의 등장은 1940년대 벨 전화 연구소로 거슬러 올라간다. 복잡한 공학 프로젝트에서 부분들의 합의 특성과 크게 다를 수 있는 시스템 전체의 속성을 식별하고 조작할 필요성 때문에 다양한 산업에서 이 분야를 적용하게 되었다. 이 분야에서 기능 모델을 처음 정의한 사람 중 한 명은 영국 엔지니어 윌리엄 고슬링이었다. 그는 저서 "공학 시스템의 설계(The design of engineering systems)"(1962, p. 25)에서 다음과 같이 언급했다.
최초의 잘 정의된 기능 모델 중 하나는 1950년대 국방 관련 기업인 TRW에서 개발한 기능 흐름 블록 다이어그램(FFBD)이었다. 1960년대에는 NASA에서 우주 시스템 및 비행 임무의 시간 순서 이벤트를 시각화하는 데 사용되었다. 이는 시스템 공학에서 시스템 기능의 실행 순서를 보여주기 위해 널리 사용된다.
기능 모델링 주제.
기능적 관점.
시스템 공학 및 소프트웨어 공학에서 기능 모델은 기능적 모델링 관점으로 생성된다. 기능적 관점은 비즈니스 프로세스 모델링에서 가능한 관점 중 하나이며, 다른 관점으로는 행동, 조직 또는 정보적 관점이 있다.
기능적 모델링 관점은 동적 시스템을 설명하는 데 중점을 둔다. 이 모델링 관점의 주요 개념은 프로세스이며, 이는 기능, 변환, 활동, 작업, 태스크 등이 될 수 있다. 이 관점을 사용하는 모델링 언어의 잘 알려진 예시로는 데이터 흐름 다이어그램이 있다.
이 관점은 프로세스를 설명하기 위해 네 가지 기호를 사용한다.
이제 이러한 기호를 사용하여 프로세스를 이러한 기호의 네트워크로 표현할 수 있다. 이렇게 분해된 프로세스는 DFD, 즉 데이터 흐름 다이어그램이다.
동적 엔터프라이즈 모델링에서는 제어 모델, 기능 모델, 프로세스 모델 및 조직 모델로 구분된다.
기능 분해.
기능 분해는 넓게는 함수적 관계를 구성 요소로 분해하여 원래 함수를 함수 합성을 통해 재구성할 수 있도록 하는 프로세스를 의미한다. 일반적으로 이 분해 프로세스는 구성 요소의 정체를 파악하거나 전체 함수의 압축된 표현을 얻기 위해 수행되는데, 이는 구성 프로세스가 특정 수준의 모듈성을 가질 때만 가능하다.
기능 분해는 컴퓨터 프로그래밍에서 중요한 역할을 하며, 주요 목표는 프로세스를 가능한 한 최대한 모듈화하는 것이다. 예를 들어, 도서관 관리 시스템은 재고 모듈, 사용자 정보 모듈, 요금 책정 모듈로 분리될 수 있다. 컴퓨터 프로그래밍의 초기 수십 년 동안 이것은 일부 저명한 실무자들이 "서브루틴화의 기술"이라고 불렀던 것으로 나타났다.
공학 시스템의 기능 분해는 공학 시스템을 분석하는 방법이다. 기본 아이디어는 블록 다이어그램의 각 블록을 설명에서 "및" 또는 "또는" 없이 설명할 수 있도록 시스템을 분할하는 것이다.
이 연습은 시스템의 각 부분이 순수한 기능을 갖도록 한다. 시스템이 순수한 기능으로 구성될 때, 그 기능들은 재사용되거나 교체될 수 있다. 일반적인 부작용은 블록 간의 인터페이스가 단순하고 일반적이 된다는 것이다. 인터페이스가 일반적으로 단순해지기 때문에 순수한 기능을 관련 유사한 기능으로 교체하기가 더 쉽다.
기능 모델링 방법.
기능적 접근 방식은 여러 다이어그램 기술 및 모델링 표기법으로 확장된다. 이 섹션에서는 중요한 기술을 연대순으로 설명한다.
기능 블록 다이어그램.
기능 블록 다이어그램은 시스템의 기능과 상호 관계를 설명하는 블록 다이어그램이다. 기능 블록 다이어그램은 다음을 그림으로 나타낼 수 있다.
블록 다이어그램은 특정 속성을 보여주기 위해 추가적인 회로 기호를 사용할 수 있다.
특정 기능 블록 다이어그램으로는 고전적인 기능 흐름 블록 다이어그램과 프로그래머블 로직 컨트롤러 설계에 사용되는 기능 블록 다이어그램 (FBD)이 있다.
기능 흐름 블록 다이어그램.
기능 흐름 블록 다이어그램 (FFBD)은 시스템의 기능적 흐름을 다단계, 시간 순서, 단계별로 보여주는 흐름도이다.
이 다이어그램은 1950년대에 개발되어 고전적인 시스템 공학에서 널리 사용된다. 기능 흐름 블록 다이어그램은 기능 흐름 다이어그램, 기능 블록 다이어그램, 기능 흐름이라고도 불린다.
기능 흐름 블록 다이어그램 (FFBD)은 일반적으로 시스템의 상세한 단계별 운영 및 지원 순서를 정의하지만, 시스템을 개발하고 생산하는 프로세스를 정의하는 데도 효과적으로 사용된다. 소프트웨어 개발 프로세스도 FFBD를 광범위하게 사용한다. 시스템 컨텍스트에서 기능 흐름 단계는 하드웨어, 소프트웨어, 인력, 시설 및 절차의 조합을 포함할 수 있다.
FFBD 방식에서 기능은 논리적 실행 순서에 따라 구성되고 묘사된다. 각 기능은 다른 기능의 실행 및 완료와의 논리적 관계와 관련하여 표시된다. 기능 이름이 붙은 노드는 각 기능을 묘사한다. 왼쪽에서 오른쪽으로 향하는 화살표는 기능의 실행 순서를 보여준다. 논리 기호는 기능의 순차적 또는 병렬 실행을 나타낸다.
HIPO 및 IPO.
HIPO (Hierarchical Input Process Output, 계층적 입력 처리 출력)는 1970년대에 널리 사용된 시스템 분석 설계 보조 및 문서화 기법으로, 시스템의 모듈을 계층으로 나타내고 각 모듈을 문서화하는 데 사용되었다.
이는 요구 사항을 개발하고, 설계를 구축하며, 자동화된 랑데부를 시연하기 위한 전문가 시스템의 구현을 지원하는 데 사용되었다. 설계 및 구현 방법론 때문에 검증이 체계적으로 수행되었다.
시스템의 전체 설계는 HIPO 차트 또는 구조도를 사용하여 문서화된다. 구조 차트는 조직도와 유사한 모양이지만, 추가적인 세부 사항을 보여주기 위해 수정되었다. 구조 차트는 여러 유형의 정보를 표시하는 데 사용될 수 있지만, 주로 자료 구조 또는 코드 구조를 도표화하는 데 사용된다.
N2 차트.
N2 차트는 행렬 형태로, 시스템 요소 간의 기능적 또는 물리적 인터페이스를 나타낸다. 이는 기능적 및 물리적 인터페이스를 체계적으로 식별, 정의, 표로 작성, 설계 및 분석하는 데 사용된다. 이는 시스템 인터페이스와 하드웨어 및 소프트웨어 인터페이스에 적용된다.
N2 다이어그램은 주로 소프트웨어 영역에서 데이터 인터페이스를 개발하는 데 광범위하게 사용되어 왔다. 그러나 하드웨어 인터페이스를 개발하는 데도 사용될 수 있다. 기본 N2 차트는 그림 2에 나와 있다. 시스템 기능은 대각선에 배치되며, N × N 행렬의 나머지 사각형은 인터페이스 입력 및 출력을 나타낸다.
구조화된 분석 및 설계 기법.
구조화된 분석 및 설계 기법 (SADT)은 시스템을 기능의 계층으로 설명하기 위한 소프트웨어 공학 방법론으로, 소프트웨어 응용 프로그램의 스케치를 구성하기 위한 다이어그램 표기법이다. 이는 개체와 활동을 나타내는 구성 블록과 상자를 연결하는 다양한 화살표를 제공한다. 이러한 상자와 화살표는 연관된 비공식적 의미론을 갖는다. SADT는 연속적인 세부 수준을 사용하여 주어진 프로세스의 기능 분석 도구로 사용될 수 있다. SADT 방법은 산업 정보 시스템에서 사용되는 IT 개발에 대한 사용자 요구 사항을 정의할 수 있을 뿐만 아니라 활동의 제조 프로세스, 절차를 설명하고 제시할 수 있다.
SADT는 회사 내의 기능과 그 관계를 설명함으로써 어떤 기업이든 특정 기능적 관점을 제공한다. 이러한 기능은 판매, 주문 계획, 제품 설계, 부품 제조, 인적 자원 관리와 같은 회사의 목표를 달성한다. SADT는 간단한 기능적 관계를 나타낼 수 있으며, 서로 다른 기능 간의 데이터 및 제어 흐름 관계를 반영할 수 있다. IDEF0 형식은 더글러스 T. 로스가 1985년에 개발한 SADT를 기반으로 한다.
IDEF0.
IDEF0는 제조업 기능을 설명하기 위한 기능 모델링 방법론으로, 정보 시스템, 비즈니스 프로세스 또는 소프트웨어 공학 분석을 위한 기능적 모델링 언어를 제공한다. 이는 소프트웨어 공학 분야의 IDEF 모델링 언어 계열의 일부이며, SADT를 기반으로 구축되었다.
IDEF0 기능 모델링 방법은 조직 또는 시스템의 결정, 행동 및 활동을 모델링하도록 설계되었다. 이는 더글러스 T. 로스와 SofTech, Inc.가 개발한 기존의 그래픽 모델링 언어인 구조화된 분석 및 설계 기법 (SADT)에서 파생되었다. 원래 형태로 IDEF0는 그래픽 모델링 언어의 정의(통사론 및 의미론)와 모델 개발을 위한 포괄적인 방법론에 대한 설명을 모두 포함한다. 미국 공군은 SADT 개발자들에게 시스템의 기능적 관점을 분석하고 전달하기 위한 기능 모델 방법을 개발하도록 의뢰했다. IDEF0는 시스템 분석을 체계화하고 단순화된 그래픽 장치를 통해 분석가와 고객 간의 효과적인 의사소통을 촉진하는 데 도움이 되어야 한다.
공리적 설계.
공리적 설계는 제품, 정보 시스템, 비즈니스 프로세스 또는 소프트웨어 공학 솔루션의 분석, 개발, 재공학 및 통합을 위한 솔루션 합성 프레임워크로 사용되는 하향식 계층적 기능 분해 프로세스이다. 그 구조는 잠재적 기능 솔루션 모델의 아키텍처 견고성을 최적화하기 위해 기능 간의 결합을 수학적으로 분석하는 데 적합하다.
관련 모델 유형.
시스템 및 소프트웨어 공학 분야에서는 수많은 특정 기능 및 기능 모델과 밀접하게 관련된 모델이 정의되었다. 여기서는 몇 가지 일반적인 유형만 설명한다.
비즈니스 기능 모델.
비즈니스 기능 모델(BFM)은 조직의 임무를 수행하기 위해 일상적으로 수행되는 운영의 일반적인 설명 또는 범주이다. 이는 "일반적인 비즈니스 기능을 식별하기 위한 개념적 구조를 제공한다". 이는 비즈니스 영역 기능의 맥락에서 중요한 비즈니스 프로세스를 보여줄 수 있다. 비즈니스 기능 모델의 프로세스는 가치 사슬 모델의 프로세스와 일치해야 한다. 프로세스는 최종 제품을 생산하거나 서비스를 제공하기 위해 수행되는 관련 비즈니스 활동 그룹이다. 지속적으로 수행되는 비즈니스 기능과 달리 프로세스는 특정 시작점과 원하는 출력이 제공되는 종료점을 특징으로 한다. 오른쪽 그림은 비즈니스 프로세스, 비즈니스 기능 및 비즈니스 영역의 비즈니스 참조 모델 간의 관계를 나타낸다.
비즈니스 프로세스 모델 및 표기법.
비즈니스 프로세스 모델 및 표기법 (BPMN)은 워크플로에서 비즈니스 프로세스를 지정하기 위한 그래픽 표현이다. BPMN은 비즈니스 프로세스 관리 이니셔티브 (BPMI)에 의해 개발되었으며, 2005년에 두 조직이 합병한 이후 현재 객체 관리 그룹에서 유지 관리하고 있다. BPMN의 현재 버전은 2.0이다.
비즈니스 프로세스 모델 및 표기법(BPMN) 사양은 비즈니스 프로세스 다이어그램(BPD)에서 비즈니스 프로세스를 지정하기 위한 그래픽 표기법을 제공한다. BPMN의 목표는 비즈니스 사용자에게 직관적이면서도 복잡한 프로세스 의미를 나타낼 수 있는 표기법을 제공함으로써 기술 사용자 및 비즈니스 사용자 모두를 위한 비즈니스 프로세스 관리를 지원하는 것이다. BPMN 사양은 또한 표기법의 그래픽과 실행 언어의 기본 구성 요소, 특히 BPEL4WS 간의 매핑을 제공한다.
비즈니스 참조 모델.
비즈니스 참조 모델은 기업, 서비스 조직 또는 관청의 핵심 비즈니스의 기능적 및 조직적 측면에 중점을 둔 참조 모델이다. 기업 공학에서 비즈니스 참조 모델은 엔터프라이즈 아키텍처 프레임워크 또는 아키텍처 프레임워크의 일부이며, 이는 엔터프라이즈 아키텍처와 관련된 구조 및 뷰를 구성하는 방법을 정의한다.
일반적인 참조 모델은 어떤 것의 기본 목표나 아이디어를 구현하고 다양한 목적으로 참조될 수 있는 모델이다. 비즈니스 참조 모델은 조직의 조직 구조와 독립적으로 비즈니스 운영을 설명하는 수단이다. 다른 유형의 비즈니스 참조 모델은 비즈니스 프로세스, 비즈니스 기능, 비즈니스 영역의 비즈니스 참조 모델 간의 관계를 나타낼 수도 있다. 이러한 참조 모델은 계층으로 구성될 수 있으며, 서비스 구성 요소, 기술, 데이터 및 성능 분석의 기초를 제공한다.
운영자 기능 모델.
운영자 기능 모델(OFM)은 인적 요인 엔지니어가 사용하는 전통적인 과업 분석 기술의 대안으로 제안되었다. 운영자 기능 모델은 운영자가 복잡한 시스템을 더 간단한 부분으로 분해하고 제어 동작 및 시스템 구성을 조정하여 허용 가능한 전체 시스템 성능을 달성하는 방법을 수학적 형태로 표현하려고 시도한다. 이 모델은 복잡한 시스템의 지식 표현, 정보 흐름 및 의사결정의 기본 문제를 나타낸다. 밀러(1985)는 네트워크 구조가 시스템에 대한 운영자의 내부 모델과 운영자 제어 기능을 구성하는 결정 문제를 해결하는 데 모델이 어떻게 사용되는지를 지정하는 제어 구조의 가능한 표현으로 간주될 수 있다고 제안한다.
프로세스 모델(process model)이라는 용어는 다양한 맥락에서 사용된다. 예를 들어, 비즈니스 프로세스 모델링에서 기업 프로세스 모델은 종종 비즈니스 프로세스 모델이라고 불린다.
프로세스 모델은 동일한 성격의 프로세스(process)를 하나의 모델로 분류한 것이다. 따라서 프로세스 모델은 유형 수준의 프로세스에 대한 설명이다. 프로세스 모델은 유형 수준이므로 프로세스는 그 인스턴스화이다. 동일한 프로세스 모델이 많은 애플리케이션 개발에 반복적으로 사용되므로 많은 인스턴스화를 가진다. 프로세스 모델의 가능한 용도 중 하나는 실제로 일어나는 프로세스 자체와 대조적으로 사물이 어떻게 이루어져야/할 수/있을 수 있는지 규정하는 것이다. 프로세스 모델은 프로세스가 어떻게 보일지에 대한 대략적인 예상이다. 프로세스가 무엇이 될지는 실제 시스템 개발 중에 결정될 것이다.
프로세스 모델의 목표는 다음과 같다:
이론적인 관점에서 메타 프로세스 모델링은 개발 프로세스에서 무엇이, 무엇에 대해, 언제, 왜 발생하는지 설명하는 데 필요한 핵심 개념을 설명한다. 운영적인 관점에서 메타 프로세스 모델링은 방법 엔지니어와 애플리케이션 개발자에게 지침을 제공하는 것을 목표로 한다.
사업 프로세스를 모델링하는 활동은 일반적으로 프로세스를 변경하거나 수정해야 할 문제를 식별해야 할 필요성을 전제한다. 이러한 변환은 IT 참여를 필요로 할 수도 있고 그렇지 않을 수도 있지만, 이는 사업 프로세스를 모델링해야 하는 일반적인 동인이다. 변화관리 프로그램은 프로세스를 실제로 적용하기 위해 필요하다. 대규모 플랫폼 공급업체의 기술 발전과 함께, 비즈니스 프로세스 모델(BPM)이 완전히 실행 가능하게 되고 (왕복 엔지니어링이 가능하게) 현실에 더욱 가까워지고 있다. 지원 기술에는 통합 모델링 언어(UML), 모델 구동형 아키텍처, 서비스 지향 아키텍처가 포함된다.
프로세스 모델링은 기업 비즈니스 아키텍처의 프로세스 측면을 다루며, 포괄적인 엔터프라이즈 아키텍처로 이어진다. 기업 시스템, 데이터, 조직 구조, 전략 등 나머지 요소의 맥락에서 비즈니스 프로세스의 관계는 변화를 분석하고 계획하는 데 더 큰 역량을 제공한다. 실제 사례 중 하나는 기업 인수 합병이다. 양사 프로세스를 자세히 이해하면 경영진이 중복을 식별하여 더 원활한 합병을 가능하게 한다.
프로세스 모델링은 항상 비즈니스 프로세스 재설계의 핵심 측면이었고, 6 시그마에서 볼 수 있는 지속적인 개선 접근 방식의 핵심이었다.
프로세스 모델의 분류.
범위별.
프로세스 모델이라는 용어가 다르게 정의된 다섯 가지 범위 유형이 있다.
정렬별.
프로세스는 다양한 종류가 있을 수 있다. 이러한 정의는 "프로세스가 모델링될 수 있는 다양한 방식에 해당한다".
세분성별.
세분성은 프로세스 모델의 세부 수준을 나타내며, 제공될 수 있는 지침, 설명 및 추적의 종류에 영향을 미친다. 거친 세분성은 이러한 것들을 상당히 제한된 세부 수준으로 제한하는 반면, 미세한 세분성은 더 자세한 기능을 제공한다. 필요한 세분성의 특성은 당면한 상황에 따라 달라진다.
프로젝트 관리자, 고객 대표, 일반, 최고 수준 또는 중간 관리자는 의사 결정을 위해 시간, 예산 및 자원 계획에 대한 개요를 얻고자 하므로 상당히 거친 수준의 프로세스 설명이 필요하다. 이와 대조적으로, 소프트웨어 엔지니어, 사용자, 테스터, 분석가 또는 소프트웨어 시스템 설계자는 모델의 세부 사항이 지침과 사람 간의 종속성과 같은 중요한 실행 종속성을 제공할 수 있는 미세한 수준의 프로세스 모델을 선호할 것이다.
미세한 모델에 대한 표기법이 존재하지만, 대부분의 전통적인 프로세스 모델은 거친 수준의 설명이다. 프로세스 모델은 이상적으로는 광범위한 세분성을 제공해야 한다(예: Process Weaver).
유연성별.
프로세스 모델이 규범적이지만 실제로는 규범에서 벗어날 수 있다는 사실이 밝혀졌다. 따라서 시스템 개발 방법이 특정 조직 상황에 맞도록 조정되어 유용성을 향상시키는 프레임워크가 발전했다. 이러한 프레임워크의 개발은 상황별 방법 공학이라고도 불린다.
방법 구성 접근 방식은 '낮음'에서 '높음'까지 유연성 스펙트럼으로 구성될 수 있다.
이 스펙트럼의 '낮은' 끝에는 엄격한 방법이 있고, '높은' 끝에는 모듈형 방법 구성이 있다. 엄격한 방법은 완전히 사전에 정의되어 있으며 당면한 상황에 맞게 조정할 여지가 거의 없다. 반면에 모듈형 방법은 주어진 상황에 맞게 수정하고 확장할 수 있다. 엄격한 방법을 선택하면 각 프로젝트가 엄격하고 사전에 정의된 방법 패널에서 자신의 방법을 선택할 수 있으며, 방법 내에서 경로를 선택하는 것은 당면한 상황에 적합한 경로를 선택하는 것으로 구성된다. 마지막으로, 방법을 선택하고 조정하면 각 프로젝트가 다른 접근 방식에서 방법을 선택하고 프로젝트의 필요에 맞게 조정할 수 있다.
방법의 품질.
이 논문에서 프로세스 모델의 품질이 논의되고 있으므로, 프로세스 모델의 품질에서 중요한 본질로서 모델링 기술의 품질을 상세히 설명할 필요가 있다. 기존 품질 이해를 위해 만들어진 대부분의 프레임워크에서 모델링 기술의 품질과 해당 기술을 적용한 결과인 모델의 품질 사이의 경계가 명확하게 구분되지 않는다. 이 보고서는 이 둘을 명확하게 구분하기 위해 프로세스 모델링 기술의 품질과 프로세스 모델의 품질 모두에 초점을 맞출 것이다.
프로세스 모델링 기술의 품질을 이해하는 데 도움이 되도록 다양한 프레임워크가 개발되었는데, 한 가지 예시로 Q-Me 프레임워크로 알려진 품질 기반 모델링 평가 프레임워크가 있다. 이 프레임워크는 잘 정의된 품질 속성 및 절차 세트를 제공하여 이러한 속성에 대한 객관적인 평가를 가능하게 한다고 주장했다.
이 프레임워크는 또한 하나의 모델링 기술을 사용하여 하나 또는 다른 모델 유형 내의 모델 요소를 통일되고 공식적으로 설명하는 장점이 있다.
요컨대, 이는 이전에 정의된 속성 집합에 대해 모델링 기술의 제품 품질과 프로세스 품질을 모두 평가할 수 있게 한다.
에서 논의된 비즈니스 프로세스 모델링 기술과 관련된 품질 속성은 다음과 같다.
Q-ME 프레임워크의 품질을 평가하기 위해, 조직의 동적 필수 요소 모델링(DEMO) 비즈니스 모델링 기술의 품질을 설명하는 데 사용되었다.
Q-ME 프레임워크를 DEMO 모델링 기술에 대한 평가 결과 Q-ME의 단점이 드러났다고 명시되어 있다. 특히 비즈니스 모델링 기술의 품질을 표현하는 정량화할 수 있는 측정 기준이 포함되어 있지 않아 전반적인 평가에서 다른 기술의 품질을 비교하기 어렵게 만든다.
또한 Rossi 등 (1996)이 제안한 복잡성 메트릭으로 알려진 모델링 기술의 품질 측정에 대한 체계적인 접근 방식도 있다. 메타 모델의 기술은 이러한 복잡성 메트릭을 계산하는 기본으로 사용된다. 크로그스티가 제안한 품질 프레임워크와 비교할 때, 품질 측정은 개별 모델 수준보다는 기술 수준에 더 초점을 맞춘다.
저자들(Cardoso, Mendling, Neuman and Reijers, 2006)은 복잡성 측정 기준을 사용하여 설계의 단순성과 이해성을 측정했다. 이는 Mendling 등이 주장한 후속 연구에 의해 지지된다. 그들은 모델의 품질 속성에 대한 질문을 돕기 위해 품질 측정 기준을 사용하지 않으면 간단한 프로세스도 복잡하고 부적절한 방식으로 모델링될 수 있다고 주장했다. 이는 결국 이해도를 낮추고, 유지보수 비용을 높이며, 문제의 프로세스 실행 비효율성을 초래할 수 있다.
모델링 기술의 품질은 품질 높은 모델을 생성하고 모델의 정확성과 유용성에 기여하는 데 중요하다.
모델의 품질.
초기 프로세스 모델은 관련 개념, 사용 가능한 기술, 특정 구현 환경, 프로세스 제약 조건 등에 따라 인스턴스화하여 얻은 실제 프로세스로 프로세스의 역동성을 반영했다.
모델의 품질에 대한 수많은 연구가 진행되었지만, 프로세스 모델의 품질에 대한 초점은 덜 옮겨졌다. 프로세스 모델의 품질 문제는 철저하게 평가될 수 없지만, 이를 위한 네 가지 주요 지침과 프레임워크가 실제로 존재한다. 이들은: 하향식 품질 프레임워크, 품질 측면과 관련된 상향식 메트릭, 모델링 기술과 관련된 실증적 조사, 그리고 실용적인 지침이다.
Hommes는 Wang 등 (1994)의 말을 인용하여, 모델 품질의 모든 주요 특성은 정확성과 유용성의 두 가지 그룹으로 분류될 수 있다고 말했다. 정확성은 모델이 모델링된 현상과의 일치성부터 모델링의 구문 규칙과의 일치성까지 다양하며, 모델이 사용되는 목적과는 독립적이다.
반면, 유용성은 모델이 처음 구성된 특정 목적에 유용하다는 것으로 볼 수 있다. Hommes는 또한 내부 정확성(경험적, 구문적, 의미적 품질)과 외부 정확성(유효성)을 추가적으로 구분한다.
개념 모델의 품질을 정의하는 일반적인 시작점은 모델링 언어의 언어적 속성을 살펴보는 것이며, 그 중 구문과 의미가 가장 자주 적용된다.
또한, Krogstie가 SEQUAL이라는 하향식 품질 프레임워크를 사용하여 수행한 것처럼, 언어학보다는 기호학에 기반을 둔 더 넓은 접근 방식도 있다. 이 프레임워크는 모델, 지식 외부화, 도메인, 모델링 언어, 그리고 학습, 행동, 모델링 활동 간의 관계를 기반으로 여러 품질 측면을 정의한다.
하지만 이 프레임워크는 다양한 품질의 정도를 결정하는 방법을 제공하지는 않지만, 수행된 경험적 테스트에서 비즈니스 프로세스 모델링에 광범위하게 사용되었다.
Moody 등의 이전 연구에 따르면, Lindland 등 (1994)이 제안한 개념 모델 품질 프레임워크를 사용하여 프로세스 모델의 품질을 평가한 결과 세 가지 수준의 품질이 확인되었다.
연구 결과, 품질 프레임워크가 프로세스 모델의 품질 평가에 사용하기 쉽고 유용하다는 것이 밝혀졌지만, 신뢰성 및 결함 식별의 어려움이라는 한계가 있었다. 이러한 한계는 크로그스티의 후속 연구를 통해 프레임워크가 개선되는 계기가 되었다. 이 프레임워크는 Krogstie 등(1995)이 제안한 SEQUEL 프레임워크(Krogstie &amp; Jørgensen, 2002에 의해 추가 개선)로, 세 가지 품질 측면을 추가했다.
개념적 품질 프레임워크의 차원
모델링 도메인은 문제 도메인을 설명하는 데 관련성이 있고 올바른 모든 문장들의 집합이며, 언어 확장은 사용되는 모델링 언어의 문법과 어휘가 허용하는 모든 문장들의 집합이다. 모델 외부화는 문제 도메인의 개념적 표현이다.
이는 문제 도메인에 대해 실제로 만들어진 진술들의 집합으로 정의된다. 사회적 행위자 해석과 기술적 행위자 해석은 각각 인간 모델 사용자들과 모델과 상호작용하는 도구들이 문제 도메인의 개념적 표현이 포함하고 있다고 '생각하는' 진술들의 집합이다.
마지막으로, 참가자 지식은 모델링 프로세스에 참여하는 인간 행위자들이 문제 도메인을 나타내기 위해 만들어져야 한다고 믿는 진술들의 집합이다. 이러한 품질 차원은 나중에 모델의 물리적 및 사회적 측면을 다루는 두 그룹으로 나뉘었다.
이후 작업에서 Krogstie 등은 SEQUAL 프레임워크의 확장이 초기 프레임워크의 일부 한계를 해결했지만, 다른 한계는 여전히 남아 있다고 언급했다.
특히, 프레임워크는 의미론적 품질에 대한 관점이 너무 정적이며, 주로 모델링 활동이 아닌 모델을 고려하고, 이러한 모델을 정적 도메인과 비교하기보다는 모델을 도메인 변경의 촉진자로 본다.
또한, 프레임워크의 실용적 품질 정의는 매우 협소하며, Morris의 기호학에 따라 이해에 중점을 두지만, 언어학 및 기호학의 새로운 연구는 단순한 이해를 넘어 모델이 어떻게 사용되고 해석자에게 영향을 미치는지에 초점을 맞추고 있다.
기호학적 품질 프레임워크에서 보다 동적인 관점의 필요성은 프로세스 모델을 고려할 때 특히 명백하다. 프로세스 모델 자체는 종종 문제 도메인에서 행동을 규정하거나 심지어 실행하므로, 모델의 변경은 문제 도메인을 직접적으로 변경할 수도 있다. 이 논문은 활성 프로세스 모델과 관련하여 품질 프레임워크를 논의하고 이를 기반으로 개정된 프레임워크를 제안한다.
Krogstie 등(2006)은 활성 프로세스 모델에 더 적합하도록 SEQUAL 프레임워크를 수정하기 위해 이전 연구보다 더 좁은 해석으로 물리적 품질을 재정의했다.
사용 중인 또 다른 프레임워크는 일반 회계 원칙에 기반을 둔 모델링 지침(GoM)으로, 다음 여섯 가지 원칙을 포함한다: 정확성, 명확성은 모델 시스템의 이해도와 명시성(시스템 설명)을 다룬다.
이해도는 정보 객체의 그래픽적 배열과 관련되며, 따라서 모델의 이해도를 지원한다.
관련성은 모델과 제시되는 상황과 관련된다. 비교 가능성은 모델을 비교할 수 있는 능력, 즉 두 모델 간의 의미적 비교를 포함하며, 경제적 효율성은 설계 프로세스의 생성 비용이 최소한 제안된 비용 절감 및 수익 증가로 충당되어야 한다.
조직의 목적은 대부분의 경우 이윤 극대화이므로, 이 원칙은 모델링 프로세스의 경계를 정의한다. 마지막 원칙은 체계적인 설계로, 모델링 내에서 다양한 관점 간에 수용 가능한 차별화가 있어야 함을 정의한다.
정확성, 관련성, 경제적 효율성은 모델 품질의 전제 조건이며 충족되어야 하지만, 나머지 지침은 선택 사항이지만 필요하다.
SEQUAL과 GOM이라는 두 가지 프레임워크는 모델링에 능숙하지 않은 사람이 사용할 수 없다는 한계가 있다. 이들은 주요 품질 측정 기준을 제공하지만 비전문가가 쉽게 적용하기 어렵다.
프로세스 모델의 품질 측면과 관련된 상향식 메트릭의 사용은 모델링 비전문가가 다른 두 프레임워크를 사용하는 격차를 해소하려는 시도이지만, 대부분 이론적이며 그 사용을 뒷받침하는 경험적 테스트는 수행되지 않았다.
수행된 대부분의 실험은 메트릭과 품질 측면 간의 관계와 관련되며, 이러한 작업은 다양한 저자에 의해 개별적으로 수행되었다. Canfora 등은 주로 개수 메트릭(예: 작업 또는 분할 수 - 소프트웨어 프로세스 모델의 유지보수성) 간의 연결을 연구한다. Cardoso는 제어 흐름 복잡성과 인지된 복잡성 간의 상관관계를 검증한다. 그리고 Mendling 등은 프로세스 모델에서 교착 상태와 같은 제어 흐름 오류를 예측하는 데 메트릭을 사용한다.
결과는 모델의 크기가 증가하면 품질과 이해도가 감소하는 것으로 나타났다.
Mendling 등의 추가 연구는 메트릭과 이해도 간의 연결을 조사한다. 그리고 일부 메트릭이 그 효과에 대해 확인되었지만, 모델러의 역량과 같은 개인적인 요인도 모델에 대한 이해에 중요함이 밝혀졌다.
수행된 여러 경험적 조사는 여전히 프로세스 모델의 품질을 평가하는 명확한 지침이나 방법을 제공하지 못하지만, 모델러가 이 작업을 수행하는 데 필요한 명확한 지침 세트가 필요하다. 실용적인 지침은 다양한 실무자들에 의해 제안되었지만, 실제에서 그러한 지침을 모두 설명하는 것은 어렵다.
대부분의 가이드라인은 쉽게 실행되지 않지만, "동사-명사 활동 레이블 지정" 규칙은 다른 실무자들이 이전에 제안하고 경험적으로 분석했다.
연구에서 프로세스 모델의 가치는 그래픽 구성 요소의 선택뿐만 아니라 분석해야 할 텍스트 레이블로 주석을 다는 것에도 달려 있다는 것이 밝혀졌다. 그 결과 다른 레이블링 스타일보다 이해 측면에서 더 나은 모델을 생성한다는 것을 알 수 있었다.
이전 연구 및 프로세스 모델 품질 평가 방식에서 프로세스 모델의 크기, 구조, 모델러의 전문성 및 모듈성이 전반적인 이해도에 영향을 미친다는 것이 확인되었다.
이를 바탕으로 7가지 프로세스 모델링 가이드라인(7PMG)이 제시되었다. 이 가이드라인은 동사-객체 스타일뿐만 아니라 모델의 요소 수, 구조화된 모델링의 적용, 프로세스 모델의 분해에 대한 가이드라인을 사용한다. 가이드라인은 다음과 같다.
7PMG는 여전히 다음과 같은 사용상의 한계를 가진다: 유효성 문제 7PMG는 프로세스 모델의 내용에 관련되지 않고, 오직 그 내용이 조직되고 표현되는 방식에만 관련된다.
이는 내용이 그대로 유지되는 동안 프로세스 모델의 다른 구조를 조직하는 방법을 제안하지만, 모델에 무엇을 포함해야 하는지에 대한 실용적인 문제는 여전히 남아 있다.
두 번째 한계는 우선순위 지정 가이드라인과 관련되어 있다. 도출된 순위는 21명의 프로세스 모델러의 참여에만 의존하므로 경험적 근거가 작다.
이는 한편으로 프로세스 모델러의 경험에 대한 더 넓은 참여의 필요성으로 볼 수 있지만, 다른 한편으로는 우선순위 지정 가이드라인에 도달하기 위한 다른 접근 방식이 무엇이 있을 수 있는지에 대한 질문을 제기한다.
병렬 컴퓨팅에서 배리어(barrier)는 동기화 방법의 일종이다. 소스 코드의 스레드 또는 프로세스 그룹에 대한 배리어는 모든 스레드/프로세스가 이 지점에서 멈춰야 하며, 다른 모든 스레드/프로세스가 이 배리어에 도달할 때까지 진행할 수 없음을 의미한다.
많은 집단 루틴과 지시문 기반 병렬 언어는 암시적 배리어를 부과한다. 예를 들어, OpenMP가 포함된 포트란의 병렬 do 루프는 마지막 반복이 완료될 때까지 어떤 스레드에서도 계속할 수 없다. 이는 프로그램이 루프 완료 직후의 결과에 의존하는 경우에 대비하기 위함이다. 메시지 전달에서, (리덕션 또는 스캐터와 같은) 모든 전역 통신은 배리어를 암시할 수 있다.
병행 컴퓨팅에서 배리어는 상승 또는 하강 상태일 수 있다. '래치'라는 용어는 때때로 상승 상태로 시작하여 하강 상태가 되면 다시 상승할 수 없는 배리어를 지칭하는 데 사용된다. '카운트다운 래치'라는 용어는 미리 정해진 수의 스레드/프로세스가 도착하면 자동으로 하강하는 래치를 지칭하는 데 사용되기도 한다.
스레드 배리어로 알려진 스레드에 대한 예시를 살펴보자. 스레드 배리어는 배리어에 진입한 총 스레드 수를 추적하는 변수를 필요로 한다. 충분한 스레드가 배리어에 진입하면 배리어가 해제된다. 뮤텍스와 같은 동기화 기본요소 또한 스레드 배리어를 구현할 때 필요하다.
이 스레드 배리어 방법은 "중앙 배리어" 앞에서 대기해야 하는 스레드들이 예상된 수의 스레드가 배리어에 도달할 때까지 배리어가 해제되지 않는다는 점에서 중앙 집중식 배리어라고도 불린다.
다음은 POSIX 스레드를 사용하여 스레드 배리어를 구현한 C 코드이며, 이 절차를 보여준다:
typedef struct _thread_barrier
int thread_barrier_number;
pthread_mutex_t lock;
int total_thread;
} thread_barrier;
thread_barrier barrier;
void thread_barrier_init(thread_barrier *barrier, pthread_mutexattr_t *mutex_attr, int thread_barrier_number){
pthread_mutex_init(&amp;(barrier-&gt;lock), mutex_attr);
barrier-&gt;thread_barrier_number = thread_barrier_number;
barrier-&gt;total_thread = 0;// Init total thread to be 0
void thread_barrier_wait(thread_barrier *barrier){
if(!pthread_mutex_lock(&amp;(barrier-&gt;lock))){
barrier-&gt;total_thread += 1;
pthread_mutex_unlock(&amp;(barrier-&gt;lock));
while (barrier-&gt;total_thread &lt; barrier-&gt;thread_barrier_number);
barrier-&gt;total_thread -= 1; // Decrease one thread as it has passed the thread barrier
void thread_barrier_destroy(thread_barrier *barrier){
pthread_mutex_destroy(&amp;(barrier-&gt;lock));
void *thread_func(void *ptr){
printf("thread id %ld is waiting at the barrier, as not enough %d threads are running ...\n", pthread_self(), THREAD_BARRIERS_NUMBER);
thread_barrier_wait(&amp;barrier);
printf("The barrier is lifted, thread id %ld is running now\n", pthread_self());
pthread_t thread_id[TOTAL_THREADS];
thread_barrier_init(&amp;barrier, PTHREAD_BARRIER_ATTR, THREAD_BARRIERS_NUMBER);
for (int i = 0; i &lt; TOTAL_THREADS; i++){
pthread_create(&amp;thread_id[i], NULL, thread_func, NULL);
// As pthread_join() will block the process until all the threads it specified are finished,
// and there is not enough thread to wait at the barrier, so this process is blocked
pthread_join(thread_id[i], NULL);
thread_barrier_destroy(&amp;barrier);
printf("Thread barrier is lifted\n"); // This line won't be called as TOTAL_THREADS &lt; THREAD_BARRIERS_NUMBER
이 프로그램에서 스레드 배리어는 struct _thread_barrier라는 구조체로 정의되며, 여기에는 다음이 포함된다:
배리어의 정의에 따라, 이 프로그램에서 배리어를 해제하기 위해 프로그램의 총 스레드 수를 "모니터링"할 thread_barrier_wait()와 같은 함수를 구현해야 한다.
이 프로그램에서 thread_barrier_wait()를 호출하는 모든 스레드는 THREAD_BARRIERS_NUMBER 수의 스레드가 스레드 배리어에 도달할 때까지 차단된다.
이 프로그램의 결과는 다음과 같다:
thread id &lt;thread_id, e.g 139997337872128&gt; is waiting at the barrier, as not enough 3 threads are running ...
thread id &lt;thread_id, e.g 139997329479424&gt; is waiting at the barrier, as not enough 3 threads are running ...
// (main process is blocked as not having enough 3 threads)
// Line printf("Thread barrier is lifted\n") won't be reached
프로그램에서 볼 수 있듯이, 생성된 스레드는 단 2개뿐이다. 이 두 스레드 모두 스레드 함수 핸들러로 를 가지며, 이는 를 호출한다. 반면 스레드 배리어는 해제되기 위해 3개의 스레드가 ()를 호출할 것으로 예상한다.
TOTAL_THREADS를 3으로 변경하면 스레드 배리어가 해제된다:
thread id &lt;thread ID, e.g 140453108946688&gt; is waiting at the barrier, as not enough 3 threads are running ...
thread id &lt;thread ID, e.g 140453117339392&gt; is waiting at the barrier, as not enough 3 threads are running ...
thread id &lt;thread ID, e.g 140453100553984&gt; is waiting at the barrier, as not enough 3 threads are running ...
The barrier is lifted, thread id &lt;thread ID, e.g 140453108946688&gt; is running now
The barrier is lifted, thread id &lt;thread ID, e.g 140453117339392&gt; is running now
The barrier is lifted, thread id &lt;thread ID, e.g 140453100553984&gt; is running now
Thread barrier is lifted
센스 반전 중앙 집중식 배리어.
스레드 배리어를 성공적으로 통과한 모든 스레드에 대해 총 스레드 수를 1씩 감소시키는 것 외에도, 스레드 배리어는 스레드 상태를 통과 또는 중지로 표시하기 위해 반대 값을 사용할 수 있다. 예를 들어, 상태 값이 0인 스레드 1은 배리어에서 중지되었음을 의미하고, 상태 값이 1인 스레드 2는 배리어를 통과했음을 의미하며, 스레드 3의 상태 값 = 0은 배리어에서 중지되었음을 의미하는 식이다. 이는 센스 반전으로 알려져 있다.
다음 C 코드는 이를 보여준다:
bool flag;
barrier-&gt;total_thread = 0;
barrier-&gt;flag = false;
bool local_sense = barrier-&gt;flag;
local_sense = !local_sense;
if (barrier-&gt;total_thread == barrier-&gt;thread_barrier_number){
barrier-&gt;flag = local_sense;
while (barrier-&gt;flag != local_sense); // wait for flag
이 프로그램은 이전 중앙 집중식 배리어 소스 코드와 유사한 모든 기능을 가지고 있다. 단지 2개의 새로운 변수를 사용하여 다른 방식으로 구현할 뿐이다:
스레드가 배리어에서 멈추면 local_sense의 값이 토글된다. THREAD_BARRIERS_NUMBER 미만의 스레드가 스레드 배리어에서 멈출 때, 해당 스레드들은 struct _thread_barrier의 flag 멤버가 개인 codice_1 변수와 같지 않다는 조건 하에 계속 기다린다.
THREAD_BARRIERS_NUMBER 스레드가 스레드 배리어에서 정확히 멈추면 총 스레드 수는 0으로 재설정되고, flag는 codice_1로 설정된다.
결합 트리 배리어.
중앙 집중식 배리어의 잠재적인 문제는 모든 스레드가 통과/정지를 위해 전역 변수에 반복적으로 접근하기 때문에 통신 트래픽이 상당히 높아서 확장성이 저하된다는 점이다.
이 문제는 스레드를 재그룹화하고 다단계 배리어(예: 결합 트리 배리어)를 사용하여 해결할 수 있다. 또한 하드웨어 구현은 더 높은 확장성의 이점을 가질 수 있다.
결합 트리 배리어는 모든 스레드가 동일한 위치에서 스핀하는 상황을 피함으로써 확장성 문제를 해결하기 위해 계층적인 방식으로 배리어를 구현하는 방법이다.
k-트리 배리어에서 모든 스레드는 k개 스레드의 서브그룹으로 균등하게 나뉘고, 이 서브그룹 내에서 1차 동기화가 이루어진다. 모든 서브그룹이 동기화를 마치면 각 서브그룹의 첫 번째 스레드는 2차 동기화를 위해 다음 레벨로 진입한다. 2차 레벨에서는 1차 레벨과 마찬가지로 스레드들이 k개 스레드의 새로운 서브그룹을 형성하고 그룹 내에서 동기화하며, 각 서브그룹에서 하나의 스레드를 다음 레벨로 보내는 방식으로 진행된다. 결국, 최종 레벨에는 하나의 서브그룹만 동기화된다. 최종 레벨 동기화 후, 해제 신호가 상위 레벨로 전송되고 모든 스레드가 배리어를 통과한다.
하드웨어 배리어 구현.
하드웨어 배리어는 위의 기본 배리어 모델을 구현하기 위해 하드웨어를 사용한다.
가장 간단한 하드웨어 구현은 전용 와이어를 사용하여 신호를 전송함으로써 배리어를 구현한다. 이 전용 와이어는 OR/AND 연산을 수행하여 통과/차단 플래그 및 스레드 카운터 역할을 한다. 소규모 시스템에서는 이러한 모델이 작동하며 통신 속도가 주요 고려 사항이 아니다. 대규모 다중 프로세서 시스템에서 이 하드웨어 설계는 배리어 구현에 높은 지연 시간을 초래할 수 있다. 프로세서 간의 네트워크 연결은 지연 시간을 낮추는 한 가지 구현 방법이며, 이는 결합 트리 배리어와 유사하다.
POSIX 스레드 배리어 함수.
POSIX 스레드 표준은 직접적으로 스레드 배리어 함수를 지원하며, 이는 지정된 스레드 또는 전체 프로세스를 해당 배리어에 다른 스레드가 도달할 때까지 차단하는 데 사용될 수 있다. POSIX가 스레드 배리어를 구현하기 위해 지원하는 세 가지 주요 API는 다음과 같다:
다음 예제(C로 pthread API를 사용하여 구현됨)는 스레드 배리어를 사용하여 메인 프로세스의 모든 스레드를 차단하고 따라서 전체 프로세스를 차단할 것이다:
pthread_barrier_t barrier;
printf("Waiting at the barrier as not enough %d threads are running ...\n", THREAD_BARRIERS_NUMBER);
pthread_barrier_wait(&amp;barrier);
pthread_barrier_init(&amp;barrier, PTHREAD_BARRIER_ATTR, THREAD_BARRIERS_NUMBER);
// As pthread_join() will block the process until all the threads it specifies are finished,
pthread_barrier_destroy(&amp;barrier);
이 소스 코드의 결과는 다음과 같다:
Waiting at the barrier as not enough 3 threads are running ...
소스 코드에서 볼 수 있듯이, 생성된 스레드는 단 두 개뿐이다. 이 두 스레드는 모두 스레드 함수 핸들러인 thread_func()를 가지며, 이는 를 호출한다. 반면 스레드 배리어는 해제되기 위해 3개의 스레드가 ()를 호출할 것으로 예상한다.
The barrier is lifted, thread id 140643372406528 is running now
The barrier is lifted, thread id 140643380799232 is running now
The barrier is lifted, thread id 140643389191936 is running now
main()이 스레드로 취급되므로, 즉 프로세스의 "메인" 스레드이므로, 안에서 를 호출하면 다른 스레드가 배리어에 도달할 때까지 전체 프로세스가 차단된다. 다음 예제는 안에서 를 사용하여 프로세스/메인 스레드를 5초 동안 차단하며, 이는 2개의 "새로 생성된" 스레드가 스레드 배리어에 도달하기를 기다리는 동안이다:
sleep(5);
이 예제는 2개의 "새로 생성된" 스레드가 완료될 때까지 기다리기 위해 을 사용하지 않는다. 대신 내에서 를 호출하여 메인 스레드를 차단하므로, 2개의 스레드가 5초 대기(9행 - ) 후 작업을 완료할 때까지 프로세스가 차단된다.
C++ AMP(C++ Accelerated Massive Parallelism)는 C++ 프로그래밍 언어와 해당 런타임 라이브러리의 요소를 포함하는 네이티브 프로그래밍 모델이다. 이 모델은 데이터 병렬 하드웨어(예: 그래픽 카드 및 그래픽 처리 장치(GPU))에서 컴파일 및 실행되는 프로그램을 쉽게 작성하는 방법을 제공한다.
비주얼 스튜디오 2022(버전 17.0)부터 C++ AMP는 더 이상 지원되지 않는 것으로 선언되어 비주얼 스튜디오 2022 이후에는 지원이 종료된다.
C++ AMP는 DirectX 11에 구현된 라이브러리이며, C++에서 데이터 병렬 처리를 직접 구현하기 위한 마이크로소프트의 개방형 사양이다. 이는 개발자가 GPU 프로그래밍을 쉽게 할 수 있도록 지원하며, GPU 프로그래밍에 대한 경험이 없는 경우에도 시스템이 최선을 다해 처리하거나, 더 세밀하게 제어할 수 있으면서도 이식성을 유지하도록 의도되었다. 마이크로소프트 구현에서는 GPU에서 실행할 수 없는 코드는 대신 하나 이상의 CPU로 대체되어 SSE 명령어를 사용한다. 마이크로소프트 구현은 디버거 및 프로파일러 지원을 포함하여 비주얼 스튜디오 2012에 포함되어 있다.
마이크로소프트의 초기 C++ AMP 릴리스는 최소 윈도우 7 또는 윈도우 서버 2008 R2를 필요로 한다. C++ AMP는 개방형 사양이므로 시간이 지남에 따라 마이크로소프트 외부에서도 구현이 등장할 것이다. 이러한 초기 사례 중 하나는 클랭–LLVM 및 오픈 컴퓨팅 언어(OpenCL)에서 C++ AMP를 인텔의 실험적 구현인 Shevlin Park이다.
2013년 11월 12일, HSA 재단은 현재 C++ AMP 사양을 지원하는 OpenCL, Standard Portable Intermediate Representation (SPIR) 및 HSA Intermediate Language (HSAIL)로 출력하는 C++ AMP 컴파일러를 발표했다. 소스 코드는 https://github.com/RadeonOpenCompute/hcc에서 사용할 수 있다. C++ AMP 지원은 구식으로 간주되며, 현재 ROCm 1.9 시리즈가 이를 지원하는 마지막 버전이 될 것이다.
C++ 클래스를 사용하여 병렬 및 이기종 프로그래밍 기능을 표현하는 것과 같은 C++AMP의 기본 개념은 SYCL 표준에 영감을 주었다.
마이크로소프트는 C++ AMP 가속기에서 함수가 실행될 수 있음을 선언하기 위해 어떤 함수(람다 포함)에도 적용할 수 있는 codice_1 기능을 추가했다. 컴파일러는 관리 및 별도의 언어를 사용할 필요 없이 자동으로 컴퓨트 커널을 생성한다. restrict 키워드는 컴파일러에게 함수가 대부분의 GPU에서 지원되는 언어 기능만 사용하는지 정적으로 확인하도록 지시한다. 예를 들어, codice_2 와 같이 사용할 수 있다.
마이크로소프트 또는 개방형 C++ AMP 사양의 다른 구현자는 C++ AMP와 관련 없는 목적을 포함하여 다른 목적을 위한 다른 restrict 지정자를 추가할 수 있다.
새로운 언어 기능 외에 C++ AMP의 나머지 기능은 동시성(concurrency) 네임스페이스의 codice_3 헤더 파일을 통해 사용할 수 있다. 주요 C++ AMP 클래스는 다음과 같다: codice_4(가속기의 데이터 컨테이너), codice_5(데이터 래퍼), codice_6(N차원 점), codice_7(N차원 크기), codice_8(메모리를 할당하고 실행할 GPU와 같은 계산 리소스), codice_9(가속기의 뷰). 전역 함수 codice_10는 병렬 루프를 작성할 수 있도록 한다.