플로우 기반 프로그래밍

Flow-based programming
프로그래밍 패러다임

컴퓨터 프로그래밍에서 플로우 기반 프로그래밍(FBP)은 애플리케이션을 "블랙박스" 프로세스의 네트워크로 정의한 프로그래밍 패러다임으로, 미리 정의된 연결을 통해 데이터를 교환하고, 프로세스 외부로 연결이 지정된다.이러한 블랙박스 프로세스는 내부에서 변경할 필요 없이 끝없이 다시 연결하여 서로 다른 애플리케이션을 형성할 수 있다.따라서 FBP는 자연적으로 구성요소 지향적이다.null

FBP는 경계 버퍼, 수명이 정의된 정보 패킷, 명명된 포트 및 별도의 연결 정의에 기초한 데이터 흐름 프로그래밍의 특정한 형태다.null

소개

플로우 기반 프로그래밍은 "데이터 팩토리"라는 은유를 사용하여 응용 프로그램을 정의한다.그것은 애플리케이션을 한 시점에 시작되어 완성될 때까지 한 번에 한 가지씩 하는 하나의 순차적 프로세스가 아니라, "정보 패킷"(IP)이라고 불리는 구조화된 데이터 청크의 스트림을 통해 통신하는 비동기적 프로세스의 네트워크로 본다.이 견해에서, 포커스는 원하는 출력을 생산하기 위해 응용 프로그램 데이터와 그것에 적용되는 변환에 초점을 맞춘다.네트워크는 일반적으로 "scheduler"라고 불리는 소프트웨어 조각에 의해 해석되는 연결 목록으로서, 프로세스에 대해 외부적으로 정의된다.null

프로세스는 고정 용량 연결을 통해 통신한다.연결은 포트로 프로세스에 연결되며, 포트는 프로세스 코드와 네트워크 정의 사이에 합의된 이름을 가지고 있다.둘 이상의 프로세스가 동일한 코드를 실행할 수 있다.어느 시점에서든, 주어진 IP는 오직 하나의 프로세스에 의해서만 "소유"될 수 있고, 또는 두 프로세스 사이에 이동될 수 있다.포트는 아래에 설명된 Collate 구성 요소의 입력 포트에 대해 사용되는 간단하거나 배열 형식일 수 있다.소프트웨어 블랙박스 형태로 정렬, 병합, 요약 등 데이터 처리의 오랜 원시적 기능을 많이 지원할 수 있는 비동기적 프로세스를 가진 포트의 결합이다.null

FBP 프로세스는 작업할 데이터가 있는 한, 그리고 그들의 출력을 올릴 수 있는 곳에서 계속 실행될 수 있기 때문에, FBP 애플리케이션은 일반적으로 전통적인 프로그램보다 덜 경과된 시간에 실행되며, 이를 달성하기 위해 특별한 프로그래밍이 필요하지 않은, 기계의 모든 프로세서를 최적으로 사용한다.[1]null

네트워크 정의는 일반적으로 도식화되어 있으며, 일부 하위 수준 언어 또는 표기법으로 연결 목록으로 변환된다.FBP는 종종 이 수준에서 시각적 프로그래밍 언어다.보다 복잡한 네트워크 정의는 "sticky" 연결을 가진 서브넷에서 구축되는 계층 구조를 가지고 있다.다른 많은 흐름 기반 언어/런타임은 보다 전통적인 프로그래밍 언어를 중심으로 구축되며, 가장 주목할[citation needed] 만한 예는 흐름 그래프를 지정하기 위해 C++ 아이오스트림과 같은 연산자를 사용하는 래프트립이다.null

FBP는 겔레른터와 카리에로의 용어에서 "조정 언어"[3]라는 점에서 린다어와[2] 많은 공통점을 가지고 있다: 그것은 본질적으로 언어에 독립적이다.실제로 충분히 낮은 수준의 언어로 작성된 스케줄러에 따라, 다른 언어로 작성된 구성요소는 하나의 네트워크로 함께 연결될 수 있다.따라서 FBP는 도메인별 언어 또는 "미니 언어"의 개념에 자신을 빌려준다.null

FBP는 연결 장치에 대한 기사에서 구성 요소 간의 가장 느슨한 연결 유형으로 설명한 "데이터 연결"을 나타낸다.느슨한 결합의 개념은 차례로 서비스 지향 아키텍처의 그것과 관련되며, FBP는 비록 이 아키텍처의 대부분의 사례보다 더 세분화된 수준이지만 그러한 아키텍처에 대한 여러 기준에 적합하다.null

FBP는 시스템 동작에 대한 추론을 단순화하는 높은 수준의 기능적 사양 스타일을 촉진한다.그 예는 분산된 다당 프로토콜의 의미론을 건설적으로 지정하고 분석하기 위한 분산 데이터 흐름 모델이다.null

역사

Flow-Based Programming은 J. Paul Morrison에 의해 1970년대 초에 발명되었고, 처음에 캐나다 은행용 소프트웨어에서 시행되었다.[4]FBP는 그 시기의 일부 IBM 시뮬레이션 언어, 특히 GPSS에 의해 강한 영향을 받았으나, 그 뿌리는 콘웨이가 코루틴이라고 부르는 것에 대한 conway의 cinemal paper로 거슬러 올라간다.[5]null

FBP는 수년 동안 많은 이름 변경을 거쳤다: 원래 구현을 AMPS(Advanced Modular Processing System)라고 불렀다.1975년 캐나다에서 한 대형 어플리케이션이 가동되었고, 2013년 현재, 거의 40년 동안 매일 가동되는 지속적인 생산에 사용되고 있다.IBM은 FBP의 이면에 있는 아이디어들을 "자연 법칙과 너무 흡사하다"고 특허할 수 있다고 생각했기 때문에, 1971년에 기술 공개 게시판인 "데이터 대응 모듈, 인터리브 작업 프로그래밍 시스템"[6]을 통해 FBP의 기본 개념을 공공 영역에 투입했다.[4]그것의 개념과 그것을 사용한 경험을 기술하는 기사는 1978년 DSLM이라는 이름으로 IBM Research IBM Systems Journal에 발표되었다.[7]두 번째 구현은 IBM 캐나다와 IBM Japan의 공동 프로젝트로, "DFDM"(Data Flow Development Manager)이라는 이름으로 진행되었으며, 80년대 후반 일본에서 "Data Flow Programming Manager"라는 이름으로 잠시 마케팅되었다.null

일반적으로 IBM 내에서 개념들을 "데이터 흐름"이라고 불렀지만, 이 용어는 너무 일반적이라고 느껴졌고, 결국 "흐름 기반 프로그래밍"이라는 명칭이 채택되었다.null

80년대 초반부터 1993년까지 J. Paul Morrison과 IBM의 건축가 Wayne Stevens는 FBP 뒤에 숨겨진 개념을 다듬고 홍보했다.스티븐스는 FBP 개념을 설명하고 지지하는 몇 가지 기사를 썼고, 그것에 관한 자료를 그의 책 몇 권에 포함시켰다.[8][9][non-primary source needed][10][non-primary source needed]1994년 모리슨은 FBP를 기술하고, FBP가 개발 시간 단축으로 이어졌다는 경험적 증거를 제공하는 책을 출판했다.[11]null

개념

다음 다이어그램은 (정보 패킷과는 별개로) FBP 다이어그램의 주요 실체를 보여준다.이러한 도표는 연결 목록으로 직접 변환할 수 있으며, 그 다음 적절한 엔진(소프트웨어 또는 하드웨어)에 의해 실행될 수 있다.null

단순 FBP 다이어그램

A, B, C는 코드 구성요소를 실행하는 프로세스다.O1, O2 및 두 IN은 연결 M과 N을 각각의 프로세스에 연결하는 포트다.프로세스 B와 C가 동일한 코드를 실행할 수 있도록 허용되므로, 각 프로세스에는 자체 작업 스토리지, 제어 블록 등의 세트가 있어야 한다.그들이 공유 코드를 사용하는지 여부에 상관없이, B와 C는 동일한 포트 이름을 자유롭게 사용할 수 있다. 포트 이름은 그들을 참조하는 구성요소 내에서(물론 네트워크 수준에서) 의미를 가질 뿐이다.null

M과 N은 흔히 "경계 버퍼"라고 부르는 것으로, 어느 시점에서나 보유할 수 있는 IP의 수 측면에서 고정된 용량을 가진다.null

포트의 개념은 네트워크의 둘 이상의 장소에서 동일한 구성요소를 사용할 수 있게 하는 것이다.초기 정보 패킷(IIPs)이라는 파라메트리제이션 능력과 결합하여 포트는 FBP에 구성요소 재사용 능력을 제공하여 FBP를 구성요소 기반 아키텍처로 만든다.따라서 FBP는 IBM Research의 Raoul de Campo와 Nate Edwards가 구성 가능한 모듈화라고 칭한 것을 보여준다.null

정보 패킷 또는 IP는 "IP 공간"이라고 불릴 수 있는 곳에 할당되며(린다의 튜플이 "투플 공간"에 할당되는 것처럼), 폐기되고 그 공간이 회수될 때까지 잘 정의된 수명을 갖는다. FBP에서 이는 소유 과정의 일부에 대한 명시적인 조치여야 한다.주어진 연결을 통해 이동하는 IP들(실제로 여행하는 것은 그들의 "손"이다)은 비동기적으로 생성되고 소비되는 "스트림"을 구성한다. 따라서 이 개념은 프리드먼과 와이즈가 1976년 기사에서 설명한 게으른 반대 개념과 유사하다.[12]null

IP는 대개 구조화된 데이터 덩어리 - 그러나 일부 IP는 실제 데이터를 포함하지 않을 수 있지만 단순히 신호로 사용된다.데이터 IP를 스트림 내의 순차적 패턴으로 그룹화하는 데 사용할 수 있는 "브래킷 IP"가 그 예다.하위 프레임은 차례로 내포될 수 있다.IP는 또한 네트워크를 통해 단일 물체로 이동하는 "IP 트리"를 형성하기 위해 체인으로 연결될 수 있다.null

위에서 설명한 연결 및 프로세스 시스템은 어떤 크기로도 "라믹스"할 수 있다.애플리케이션 개발 중에 모니터링 프로세스가 프로세스 쌍 사이에 추가되거나, 프로세스가 서브넷에 "분해"되거나, 프로세스의 시뮬레이션이 실제 프로세스 논리로 대체될 수 있다.따라서 FBP는 신속한 시제품 제작에 도움이 된다.null

이것은 실제로 데이터 처리의 조립 라인 이미지인데, 프로세스 네트워크를 통해 이동하는 IP는 조립 라인에서 스테이션 간에 이동하는 위젯으로 생각할 수 있다."기계"는 쉽게 다시 연결될 수 있고, 수리를 위해 오프라인으로 전환하거나 교체할 수 있다.이상하게도, 이 이미지는 카드 덱을 한 기계에서 다른 기계로 수작업으로 운반해야 한다는 점을 제외하면 컴퓨터 시대 이전에 데이터를 처리하는 데 사용되었던 단위 기록 장비의 그것과 매우 유사하다.null

FBP의 구현은 비선제적이거나 선제적일 수 있다. 이전의 구현은 비선제적(메인프레임 및 C 언어)인 반면, 최근의 Java 구현(아래 참조)은 자바 스레드 클래스를 사용하고 선제적이다.null

예

"텔레그램 문제"

FBP 구성요소는 종종 상호 보완적인 쌍을 형성한다.이 예는 그러한 두 쌍을 사용한다.기술된 문제는 말로 기술된 것처럼 매우 간단해 보이지만, 사실 전통적인 절차적 논리로는 달성하기가 놀랄 만큼 어렵다.원래 피터 나우르에 의해 기술된 "텔레그램 문제"라고 불리는 이 과제는 텍스트의 행을 받아들이고 각 행의 문자 수가 일정 길이를 초과하지 않는 곳에서 가능한 한 많은 단어를 포함하는 출력 라인을 생성하는 프로그램을 작성하는 것이다.단어는 분할되지 않을 수 있으며, 우리는 단어가 출력 라인의 크기보다 길지 않다고 가정한다.이것은 텍스트 편집기의 단어장난감 문제와 유사하다.[13]null

종래의 논리에서는 프로그래머는 입력 구조와 출력 구조가 제어 흐름의 통화 계층 구조를 구동하는 데 사용될 수 없다는 것을 빠르게 발견한다.반면에 FBP에서는 문제 설명 자체가 다음과 같은 해결책을 제시한다.

  • 문제의 설명에 "단어"가 명시적으로 언급되어 있으므로 설계자는 단어를 정보 패킷(IP)으로 취급하는 것이 합리적이다.
  • FBP에서는 단일 통화 계층이 없기 때문에 프로그래머는 솔루션의 하위 패턴을 상위 레벨로 강제하려고 하지 않는다.

여기 FBP에서 가장 자연적인 솔루션이 있다(FBP에서는 단일 "정확한" 솔루션이 없지만, 이것은 자연 적합성처럼 보인다).null

피터 나우르의 "텔레그램 문제"

여기서 DC와 RC는 각각 "Decompose"와 "ReCompose"를 의미한다.null

위에서 언급한 바와 같이, 초기 정보 패킷(IIP)을 사용하여 원하는 출력 기록 길이(가장 오른쪽 두 구성 요소에 필요) 또는 파일 이름과 같은 파라메트릭 정보를 지정할 수 있다.IIP는 관련 포트에 대해 "수신"이 발급될 때 "정상" IP가 되는 네트워크 정의의 포트와 관련된 데이터 청크다.null

일괄 업데이트

이러한 유형의 프로그램에는 "마스터 파일"에 대해 "세부 정보"(변경, 추가 및 삭제) 파일을 전달하고, 업데이트된 마스터 파일 및 하나 이상의 보고서를 생성하는 것이 포함된다.업데이트 프로그램은 일반적으로 동기식, 절차적 코드를 사용하여 코딩하기가 상당히 어렵다. 두 개(때로는 더 많은) 입력 스트림을 동기화해야 하기 때문에, 해당 세부 정보가 없는 마스터가 있을 수도 있고, 그 반대의 경우도 있을 수 있다.null

표준 "batch update" 구조

FBP에서는 Collator의 단위 기록 아이디어에 기초한 재사용 가능한 컴포넌트(Collate)는 Collate가 두 스트림을 병합하고 괄호 IP를 삽입하여 그룹화 수준을 나타냄으로써 다운스트림 논리를 크게 단순화함으로써 이러한 유형의 응용 프로그램을 훨씬 쉽게 작성할 수 있게 한다.하나의 스트림("이 경우 마스터")이 1, 2, 3의 키 값을 가진 IP로 구성되며, 두 번째 스트림 IP("상세")는 11, 12, 21, 31, 32, 33, 41의 키 값을 가지며, 여기서 첫 번째 숫자는 마스터 키 값에 해당한다고 가정하자.브래킷 문자를 사용하여 "브래킷" IP를 나타내면, 조합된 출력 스트림은 다음과 같다.

( m1 d11 d12 ) (m2 d21 ) (m3 d31 d32 d33 ) (d41)

값이 4인 마스터가 없었기 때문에 마지막 그룹은 하나의 세부사항(더하기 괄호)으로 구성된다.null

위의 흐름의 구조는 다음과 같은 BNF와 같은 표기법을 사용하여 간결하게 설명할 수 있다.

{ ([m] d*) }*

Collate는 들어오는 IP에서 제어 필드가 어디에 있는지만 알면 되는 재사용 가능한 블랙박스(이마저도 제어 필드를 표준 위치에 배치하기 위해 상류로 변압기 공정을 삽입할 수 있기 때문에 엄격히 필요하지 않다)이며, 실제로 입력 스트림 수, 브래킷 내포 깊이 등으로 일반화할 수 있다.Collate는 입력에 어레이형 포트를 사용하며, 입력 스트림의 가변 개수를 허용한다.null

멀티플렉싱 프로세스

플로우 기반 프로그래밍은 매우 자연스러운 방법으로 프로세스 멀티플렉싱을 지원한다.구성요소는 읽기 전용이기 때문에, 주어진 구성요소("프로세스")의 모든 인스턴스(instance)가 서로 비동기적으로 실행될 수 있다.null

다중화 예제

컴퓨터가 보통 단일 프로세서를 가지고 있을 때, 이것은 많은 I/O가 실행될 때 유용했다; 이제 기계는 대개 여러 프로세서를 가지고 있기 때문에, 이것은 CPU 집약적인 프로세스에서도 유용해지기 시작했다.이 섹션의 다이어그램은 단일 구성 요소의 인스턴스인 S1, S2 및 S3라는 세 가지 프로세스 간에 각각 데이터를 분배하는 단일 "부하 밸런서" 프로세스를 보여 주며, 이는 다시 "선착된, 선착순" 기준으로 단일 프로세스로 피드를 공급한다.null

단순 인터랙티브 네트워크

일반 대화형 응용의 개략도

이 일반적인 도식에서는 사용자로부터 오는 요청(트랜잭션)이 왼쪽 상단의 도표를 입력하며, 왼쪽 하단의 응답이 반환된다."뒷면 끝"(오른쪽)은 CORBA, MQSeries 등을 사용하는 등 다른 현장의 시스템과 통신한다.상호 연결은 백 엔드로 갈 필요가 없는 요청이나, 사용자에게 반환되기 전에 네트워크를 통해 두 번 이상 순환해야 하는 요청을 나타낸다.null

서로 다른 요청이 서로 다른 백엔드를 사용할 수 있고, 백엔드(사용되는 경우)가 이를 처리하는 데 서로 다른 시간이 필요할 수 있으므로, 반환된 데이터를 해시 테이블이나 캐시와 같은 적절한 요청 트랜잭션과 연관시킬 수 있는 프로비저닝이 이루어져야 한다.null

위의 도표는 최종 응용 프로그램이 더 많은 프로세스를 포함할 수 있다는 의미에서 도식화된 것이다. 캐시를 관리하고 연결 트래픽을 표시하며 처리량을 모니터링하는 다른 프로세스 사이에 프로세스를 삽입할 수 있다.또한 다이어그램의 블록은 하나 이상의 열린 연결을 가진 작은 네트워크인 "subnets"를 나타낼 수 있다.null

다른 패러다임 및 방법론과의 비교

JSP(Jackson Structured Programming) 및 JSD(Jackson System Development)

주요 기사: 잭슨 구조 프로그래밍 및 잭슨 시스템 개발

이 방법론은 프로그램이 서브루틴의 단일 절차적 계층 구조로 구성되어야 한다고 가정한다.그것의 출발점은 애플리케이션을 입력 및 출력 데이터 구조에 기초하여 "주선"의 집합으로 설명하는 것이다.그런 다음 이러한 "주선" 중 하나를 선택해서 전체 프로그램을 구동시키고, 다른 것들은 서브루틴으로 전환하기 위해 "반전"되어야 한다("잭슨 역전"이라는 명칭을 사용함).이것은 때때로 프로그램을 여러 프로그램이나 코루틴으로 분할하도록 요구하는 "클래시"라고 불리는 결과를 초래한다.FBP를 사용할 때, 모든 FBP 구성요소는 별도의 "주선"으로 간주될 수 있기 때문에 이 반전 과정이 필요하지 않다.null

FBP와 JSP는 프로그램(또는 일부 구성요소)을 입력 스트림의 파서로서 처리하는 개념을 공유한다.null

잭슨의 후기 작품인 잭슨 시스템 개발(JSD)에서는 이러한 아이디어들이 더욱 발전되었다.[14][15]null

JSD에서 설계는 최종 구현 단계까지 네트워크 설계로 유지된다.그런 다음 모델은 일련의 순차적 프로세스로 변환되어 사용 가능한 프로세서 수에 도달한다.잭슨은 그의 저서 1.3절에서 이 단계 이전에 존재하는 네트워크 모델을 직접 실행할 가능성에 대해 논의한다(이탈론 추가).null

시스템 타이밍 단계가 끝날 때 생성되는 사양은 원칙적으로 직접 실행이 가능하다.필요한 환경에는 각 프로세스에 대한 프로세서, 각 데이터 스트림에 대한 무한 버퍼에 해당하는 장치, 그리고 시스템이 실제 세계에 연결되는 일부 입력 및 출력 장치가 포함될 것이다.물론 그러한 환경은 충분히 강력한 기계에서 실행되는 적절한 소프트웨어에 의해 제공될 수 있다. 때때로 그러한 규격의 직접 실행이 가능할 것이며, 심지어 합리적인 선택일 수도 있다.[15]

FBP는 M A 잭슨에 의해 "코루틴과 같은 메커니즘에 의해 통신하는 순차적 프로세스로 프로그램 분해"[16]라는 그의 방법을 따르는 접근법으로 인식되었다.

응용 프로그램

주요 기사:응용 프로그래밍 언어

W.B. Ackerman은 적용 언어를 값에 적용된 연산자를 통해 모든 처리를 수행하는 언어로 정의한다.[17]가장 먼저 알려진 적용 언어는 LISP였다.

FBP 구성요소는 입력 스트림을 출력 스트림으로 변환하는 기능으로 간주할 수 있다.그런 다음 다음과 같이 이러한 기능을 결합하여 보다 복잡한 변환을 만든다.

하나의 기능을 제공하는 두 가지 기능

그림과 같이 스트림에 소문자로 라벨을 붙이면 위의 도표는 다음과 같이 간결하게 나타낼 수 있다.

c = G(F(a),F(b);

기능 표기법에서 F는 값과만 작용하므로 부작용이 없기 때문에 두 번 사용할 수 있듯이, FBP에서는 주어진 성분의 두 인스턴스가 서로 동시에 실행될 수 있으므로 FBP 성분도 부작용을 가져서는 안 된다.기능 표기법은 적어도 FBP 네트워크의 일부를 나타내기 위해 명확하게 사용될 수 있다.null

그러면 FBP 성분 자체가 기능 표기법을 사용하여 표현될 수 있는지에 대한 의문이 발생한다.W.H.버지는 반복적이고 응용적인 프로그래밍 스타일을 사용하여 스트림 표현이 어떻게 개발될 수 있는지를 보여주었지만, 이 작업은 원자 값의 관점에서 이루어졌다.[18]FBP에서는 구조화된 데이터 청크(FBP IP)를 기술하고 처리할 수 있어야 한다.null

더욱이 대부분의 적용 시스템은 모든 데이터가 동시에 메모리로 이용 가능하다고 가정하는 반면에 FBP 애플리케이션은 여전히 유한한 자원을 사용하면서 장기간 실행되는 데이터 스트림을 처리할 수 있어야 한다.프리드먼과 와이즈가 버지의 작품에 '지옥한 사기꾼'이라는 개념을 더해 이를 위한 방법을 제시했다.이로써 "컨설팅"이라는 두 주장을 동시에 이용할 수 있어야 한다는 요구사항이 삭제되었다."지옥한 반대자들"은 실제로 두 주장이 모두 실현될 때까지 하나의 흐름을 구축하지 않는다. 그 전에 그것은 단지 이것을 하기 위한 "약속"을 기록한다.이것은 앞에서부터 동적으로 스트림을 실현할 수 있게 하지만, 미실현된 백엔드를 가지고 있다.개울의 끝은 과정이 끝날 때까지 미실현 상태로 남아 있는 반면, 시작은 끊임없이 이어지는 항목의 순서다.null

린다

주요기사 : 린다

FBP의 많은 개념들은 여러 해 동안 서로 다른 시스템에서 독립적으로 발견되었던 것 같다.위에 언급된 린다는 그런 사람이다.두 기술의 차이는 린다 "피라냐의 학교" 로드 밸런싱 기법에 의해 설명된다. FBP에서, 이것은 처리되기를 기다리는 IP 수가 가장 적은 목록의 구성요소로 요청을 라우팅하는 추가적인 "부하 밸런서" 구성요소가 필요하다.분명히 FBP와 린다는 밀접하게 연관되어 있고, 하나는 쉽게 다른 하나를 시뮬레이션 할 수 있다.null

객체 지향 프로그래밍

주요 기사:객체 지향 프로그래밍

OOP의 물체는 정보와 행동을 모두 구성하는 반자동 단위라고 설명할 수 있다.개체는 본질적으로 서브루틴 호출인 "방법 호출"을 통해 통신하며, 수신 개체가 속한 클래스를 통해 간접적으로 이루어진다.오브젝트의 내부 데이터는 메서드 호출을 통해서만 접근할 수 있으므로, 이것은 정보를 숨기는 형태 또는 "응집화"이다.그러나 캡슐화는 OOP보다 앞서 있다 - David Parnas는 70년대[19] 초에 그것에 관한 정석적인 기사들 중 하나를 썼고 - 컴퓨팅의 기본 개념이다.캡슐화는 블랙박스로 생각할 수 있는 FBP 구성요소의 바로 그 본질로서, 입력 데이터를 출력 데이터로 어느 정도 변환하는 것을 수행할 수 있다.FBP에서 구성요소의 규격의 일부는 수용 가능한 데이터 형식과 스트림 구조와 그것이 생성할 구조들이다.이것은 계약에 의한 설계의 형태를 이루고 있다.또한 IP의 데이터는 현재 소유하는 프로세스에 의해서만 직접 액세스할 수 있다.또한 캡슐화는 외부 프로세스가 내부 프로세스를 보호하도록 함으로써 네트워크 수준에서 구현될 수 있다.null

C에 의한 논문.엘리스와 S. 깁스는 활성 물체와 수동 물체를 구별한다.[20]수동적인 물체는 위에서 설명한 바와 같이 정보와 행동을 구성하지만, 이 행동의 시기를 결정할 수는 없다.반면에 활동적인 물체는 이것을 할 수 있다.그들의 글에서 엘리스와 깁스는 활성 물체는 수동적인 물체를 하는 것보다 유지 가능한 시스템의 개발에 훨씬 더 많은 잠재력을 가지고 있다고 말한다.FBP 애플리케이션은 FBP 프로세스가 활성 객체에 대응되는 반면 IP는 수동적 객체에 대응되는 이 두 가지 유형의 객체의 조합으로 볼 수 있다.null

배우 모델

주요 기사:배우 모델

FBP는 칼 휴이트의 배우를 입력 메시지용 포트와 제어 신호용 포트 2개로 비동기 프로세스로 간주한다.각 실행이 끝나면 행위자 자신이 제어 신호를 방출한다.이 신호의 목적은 배우의 신체가 병렬적으로 실행되는 것을 방지하고, 따라서 동기화 없이 배우 객체의 필드에 접근할 수 있도록 하기 위함.null

참고 항목

참조

  1. ^ "Flow-based Programming".
  2. ^ Carriero, Nicholas; Gelernter, David (1989). "Linda in context". Communications of the ACM. 32 (4): 444–458. doi:10.1145/63334.63337. S2CID 5900105.
  3. ^ Gelernter, David; Carriero, Nicholas (1992). "Coordination languages and their significance". Communications of the ACM. 35 (2): 97–107. doi:10.1145/129630.129635. S2CID 7748555.
  4. ^ a b Gabe Stein (August 2013). "How an Arcane Coding Method From 1970s Banking Software Could Save the Sanity of Web Developers Everywhere". Retrieved 24 January 2016.
  5. ^ Conway, Melvin E. (1963). "Design of a separable transition-diagram compiler". Communications of the ACM. 6 (7): 396–408. doi:10.1145/366663.366704. S2CID 10559786.
  6. ^ J. Paul Morrison, Data Response Modular, Interleaved Task Programming System, IBM Technical Disclosure Bulletin, Vol. 13, No. 8, 2425-2426, 1971년 1월
  7. ^ Morrison, J. P. (1978). "Data Stream Linkage Mechanism". IBM Systems Journal. 17 (4): 383–408. doi:10.1147/sj.174.0383.
  8. ^ Stevens, W. P. (1982). "How data flow can improve application development productivity". IBM Systems Journal. 21 (2): 162–178. doi:10.1147/sj.212.0162.
  9. ^ W.P. Stevens, 1985년 6월, 애플리케이션 개발에 데이터 흐름 사용
  10. ^ W.P. Stevens, 소프트웨어 설계 - 개념과 방법, 실용적인 소프트웨어 엔지니어링 시리즈, Ed.앨런 매크로, 프렌티스 홀, 1990, ISBN 0-13-820242-7
  11. ^ Johnston, Wesley M.; Hanna, J. R. Paul; Millar, Richard J. (2004). "Advances in dataflow programming languages". ACM Computing Surveys. 36 (1): 1–34. CiteSeerX 10.1.1.99.7265. doi:10.1145/1013208.1013209. S2CID 5257722.
  12. ^ D.P. 프리드먼과 D.S.Wise, CONS는 자신의 주장인 Automata, Language and Programming, Edinburgies, Edinburgh University Press, Edinburgh, 1976년에 평가해서는 안 된다.
  13. ^ "Archived copy". Archived from the original on 2014-09-06. Retrieved 2014-09-06.{{cite web}}: CS1 maint: 타이틀로 보관된 사본(링크)
  14. ^ M. A. Jackson의 "프로그래밍"은 1982년 10월 4-6일자 CERN, 제네바, 1-12페이지의 고에너지 물리학 소프트웨어 워크샵에서 출판되었다.
  15. ^ a b M. A. Jackson의 "Wayback Machine에 보관된 2012-02-06 시스템 개발 방법"은 프로그램 구축을 위한 개념 및 도구로 출판되었다. 케임브리지 대학교 출판부의 고급 과정, 1982년
  16. ^ "JSP In Perspective" 마이클 잭슨, JSP in Perspective, 소프트웨어 개척자: 소프트웨어 엔지니어링에 대한 기여, Manfred Broy, Ernst Denert eds, Springer, 2002
  17. ^ W.B. Ackerman, 데이터 흐름 언어, Processions National Computer Conference, 페이지 1087-1095, 1979
  18. ^ W.H. 버지, 재귀 프로그래밍 기술, 애디슨-웨슬리, 리딩, MA, 1975년
  19. ^ Parnas, D. L. (1972). "On the criteria to be used in decomposing systems into modules". Communications of the ACM. 15 (12): 1053–1058. doi:10.1145/361598.361623. S2CID 53856438.
  20. ^ C. Ellis와 S. Gibbs, Active Objects: 현실과 가능성, 객체 지향 개념, 데이터베이스 및 애플리케이션에서, eds.W. Kim과 F.H. 로초프스키, ACM 프레스, 애디슨 웨슬리, 1989년

외부 링크