shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
핵자기 공명 관찰 중 스핀-격자 완화(Spin–lattice relaxation)는 총 핵자기 모멘트 벡터의 종방향 성분(일정한 자기장과 평행)이 더 높은 에너지의 비평형 상태에서 주변(또는 "격자")과의 열역학적 평형 상태로 지수적으로 완화되는 메커니즘이다. 이는 스핀-격자 완화 시간 또는 T1으로 알려진 시상수로 특징지어진다.
다른 매개변수인 T2, 즉 스핀-스핀 완화 시간은 핵 자화 벡터의 횡방향 성분(외부 자기장에 )의 지수적 완화를 다룬다. 서로 다른 물질에서 T1과 T2의 변화를 측정하는 것은 일부 자기공명영상 기법의 기본이다.
T1은 다음 방정식에 따라 자화 벡터의 종방향 Mz 성분이 열역학적 평형을 향해 지수적으로 회복되는 속도를 특징짓는다.
또는 formula_2인 특정 경우:
따라서 90° 무선 주파수 펄스에 의해 자기 횡단 평면으로 뒤집힌 후 종방향 자화가 초기 값의 약 63% [1-(1/e)]를 회복하는 데 걸리는 시간이다.
핵은 분자 구조 내에 포함되어 있으며 끊임없이 진동하고 회전 운동을 하며 복잡한 자기장을 생성한다. 격자 내 핵의 열 운동으로 인해 발생하는 자기장을 격자장이라고 한다. 낮은 에너지 상태의 핵의 격자장은 높은 에너지 상태의 핵과 상호 작용하여 높은 에너지 상태의 에너지가 두 핵 사이에 분산될 수 있다. 따라서 RF 펄스로부터 핵이 얻은 에너지는 격자 내 진동 및 회전 증가로 소산되며, 이는 시료의 온도를 약간 증가시킬 수 있다. 스핀-격자 완화라는 이름은 스핀이 RF 펄스로부터 얻은 에너지를 주변 격자에 다시 전달하여 평형 상태를 회복하는 과정을 의미한다. 동일한 과정은 주변 정자기장의 변화(예: 고자기장으로의 사전 편광 또는 삽입)에 의해 스핀 에너지가 변경된 후 또는 비평형 상태가 다른 수단(예: 초편극화 광펌핑)에 의해 달성된 경우에도 발생한다.
완화 시간 T1(높은 에너지 상태의 핵의 평균 수명)은 핵의 자기회전비율과 격자의 이동성에 따라 달라진다. 이동성이 증가함에 따라 진동 및 회전 주파수가 증가하여 격자장의 구성 요소가 높은 에너지 상태에서 낮은 에너지 상태로의 전이를 자극할 가능성이 높아진다. 그러나 극도로 높은 이동성에서는 진동 및 회전 주파수가 더 이상 상태 간 에너지 간격과 일치하지 않으므로 확률이 감소한다.
조직마다 T1 값이 다르다. 예를 들어, 유체는 긴 T1(1500-2000 ms)을 가지며, 수성 조직은 400-1200 ms 범위에 있고, 지방 기반 조직은 더 짧은 100-150 ms 범위에 있다. 강자성 또는 상자성과 같은 강한 자기 이온 또는 입자의 존재도 T1 값을 크게 변경하며 MRI 조영제로 널리 사용된다.
T1 강조 영상.
자기공명영상은 양성자의 공명을 사용하여 이미지를 생성한다. 양성자는 적절한 주파수(라모어 주파수)의 무선주파수 펄스에 의해 여기되고, 스핀이 열 평형 상태로 돌아오면서 초과 에너지는 미미한 양의 열 형태로 주변에 방출된다. 양성자 앙상블의 자화는 시간 상수 T1(참조: 이완 (NMR))으로 특징지어지는 지수 곡선으로 평형 값으로 돌아간다.
T1 강조 영상은 기존 스핀 에코 시퀀스에서 짧은 반복 시간 (TR, 예: &lt; 750 ms) 및 에코 시간 (TE, 예: &lt; 40 ms)을 설정하거나, 그라디언트 에코 시퀀스에서는 플립 각도를 50°보다 크게 설정하고 TE 값을 15 ms 미만으로 설정하여 얻을 수 있다.
T1은 회색질과 백색질 사이에 유의미한 차이가 있으며 뇌 스캔 시 사용된다. T1 대조는 유체와 더 단단한 해부학적 구조 사이에 강하게 나타나므로, T1 대조는 정상 또는 병리학적 해부학의 형태학적 평가에 적합하며, 예를 들어 근골격계 적용에 사용된다.
회전 좌표계에서.
회전 좌표계에서의 스핀-격자 완화는 핵자기 공명 (NMR) 및 자기공명영상 (MRI)에서 무선주파수 (RF)장의 영향 하에 자화 벡터의 횡방향 성분인 Mxy가 영의 평형 값으로 지수적으로 감쇠하는 메커니즘이다. 이는 회전 좌표계에서의 스핀-격자 완화 시간 상수인 T1ρ로 특징지어진다. 이는 스핀-격자 완화 시간인 T1과 대비하여 명명되었다.
T1ρ MRI는 횡단 평면의 자화에 스핀-록(SL) 펄스라고 하는 장시간, 저전력 무선주파수를 사용하여 기존 T1 및 T2 MRI를 대체하는 방식이다. 자화는 인가된 B1과 비공명 성분의 벡터 합에 의해 생성된 유효 B1 장 주위에 효과적으로 스핀-록된다. 스핀-록된 자화는 T1ρ라는 시간 상수로 완화되며, 이는 자기 공명 신호가 초기 값 formula_4의 37%(1/e)에 도달하는 데 걸리는 시간이다. 따라서 다음 관계가 성립한다.
여기서 tSL은 RF 장의 지속 시간이다.
T1ρ는 스핀-록 펄스의 진폭(γB1~0.1-수 kHz)을 고정한 상태에서 스핀-록 펄스의 지속 시간에 따른 위 신호 표현을 곡선 맞춤하여 정량화(릴랙소메트리)할 수 있다. 정량적 T1ρ MRI 완화 맵은 조직의 생화학적 구성을 반영한다.
T1ρ MRI는 연골, 추간판, 뇌, 심장 및 특정 유형의 암와 같은 조직을 영상화하는 데 사용되었다.
Qiskit(Quantum Information Software Kit)은 IBM 리서치가 개발하고 2017년에 처음 출시된 양자 컴퓨팅을 위한 오픈 소스, 파이썬 기반의 고성능 소프트웨어 스택이다. 이 소프트웨어는 양자 프로그램(양자 회로 및 연산 정의를 통해)을 생성하고 이를 양자 컴퓨터 또는 고전 시뮬레이터에서 실행하기 위한 도구를 제공한다. "Qiskit"이라는 이름은 광범위하게 양자 소프트웨어 도구 모음을 지칭한다. 이는 핵심 Qiskit SDK를 중심으로 하며, 클라우드를 통해 최적화된 계산을 가능하게 하는 Qiskit Runtime 서비스와 같은 양자 계산을 위한 도구 및 서비스 모음과 결합되어 있다. Qiskit은 사용자가 양자 회로를 작성하고 이를 실제 양자 프로세서(초전도 큐비트 시스템 등) 또는 다양한 호환 가능한 양자 장치에서 실행할 수 있도록 한다. 시간이 지남에 따라 Qiskit의 기능은 Qiskit Functions 및 Qiskit 애드온과 같은 새로운 구성 요소와 개선 사항으로 확장되었으며, 양자 컴퓨팅 연구 및 애플리케이션 개발을 위한 오픈 소스 생태계를 유지하고 있다.
Qiskit SDK.
Qiskit SDK는 확장된 (정적, 동적 및 스케줄링된) 양자 회로, 연산자 및 프리미티브 수준에서 양자 컴퓨터와 작업하기 위한 핵심 소프트웨어 개발 키트이다. 파이썬 패키지 qiskit으로 배포되는 이 프레임워크는 사용자가 양자 회로를 구성하고, 양자 연산자를 조작하며, 양자 하드웨어 또는 시뮬레이터와 인터페이스할 수 있도록 하는 오픈 소스 프레임워크이다. Qiskit SDK는 Qiskit 소프트웨어 스택의 기본 구성 요소이며, 가장 큰 기능 집합을 제공하며 다른 Qiskit 서비스 및 모듈이 구축되는 기반 역할을 한다.
Qiskit SDK의 주요 기능에는 양자 회로를 구축하고 양자 연산을 등록하기 위한 모듈, 사전 정의된 양자 논리 회로 및 매개변수화된 회로 라이브러리, 양자 상태 및 연산자와 작업하기 위한 양자 정보 모듈, 특정 양자 하드웨어 백엔드에서 실행되도록 회로를 최적화하고 변환하는 트랜스파일러가 포함된다. 예를 들어, Qiskit은 사용자가 직관적인 파이썬 API를 사용하여 양자 회로를 생성한 다음, 트랜스파일러를 사용하여 특정 장치의 토폴로지 및 제약 조건에 맞게 이러한 회로를 조정하고 최적화할 수 있도록 한다(필요에 따라 게이트 수 또는 회로 깊이 감소). SDK는 또한 노이즈 모델링을 위한 도구를 제공하고 프리미티브를 지원한다 – 기본 양자 프로그램 구성 요소(회로 결과에 대한 샘플러 및 추정기와 같은) – 이는 상위 수준 양자 알고리즘의 빌딩 블록 역할을 하며 로컬 시뮬레이터 또는 클라우드 서비스를 사용하여 실행될 수 있다. 이러한 기능들이 합쳐져 Qiskit SDK는 하드웨어에 구애받지 않는 방식으로 양자 알고리즘 및 실험을 개발하기 위한 포괄적인 플랫폼이 된다.
Qiskit Runtime.
Qiskit Runtime은 IBM Quantum 시스템에서 양자 계산 실행을 간소화하기 위해 IBM이 도입한 클라우드 기반 양자 실행 서비스이다. 이 서비스는 사용자가 추가 서버 측 관리와 함께 양자 프로그램을 실행할 수 있도록 하여, 고전-양자 통신의 지연 시간을 최소화하고 고급 양자 오류 완화 기술을 활용하여 성능을 향상시킨다. 본질적으로 Qiskit Runtime은 양자 회로(또는 상위 수준 프리미티브 프로그램)가 양자 하드웨어에 더 가깝게 실행되는 IBM 클라우드에서 최적화된 환경을 제공하여, 전통적인 작업 제출 방식의 요청-응답 방식보다 대기 시간을 줄이고 더 복잡한 워크플로우를 가능하게 한다. 이 서비스는 양자 프로그램 실행을 특히 반복적인 회로 평가 또는 반복 프로세스를 포함하는 알고리즘에 대해 더 효율적이고 확장 가능하게 설계되었다.
Qiskit Runtime은 추가적인 고전 및 양자 컴퓨팅 리소스를 활용하여 양자 프로세서에서 얻은 결과의 품질과 정확도를 높이는 오류 완화 전략을 통합한다. 예를 들어, Qiskit Runtime은 동적 디커플링(회로 실행 중 노이즈를 억제하기 위해) 및 제로 노이즈 외삽 또는 기타 형태의 판독 오류 완화(측정 오류의 영향을 줄이기 위해)와 같은 기술을 자동으로 적용하여 노이즈가 많은 양자 하드웨어에서 더 높은 품질의 결과를 반환하는 것을 목표로 한다. 런타임 서비스는 또한 양자 작업을 실행하기 위한 여러 실행 모드를 지원하며, 각 모드는 다른 사용 사례에 적합하다. 사용자는 단일 작업(지정된 샷 수로 한 번의 회로 또는 프리미티브 호출)을 실행하거나, 그 사이의 오버헤드를 줄여 일련의 작업을 대화식으로 실행하기 위한 세션을 생성하거나, 큐에서 병렬 실행을 위해 배치 모드로 작업을 제출할 수 있다. 이러한 모드는 실험 관리에 유연성을 제공한다 – 예를 들어, 세션 모드는 중간 결과에 따라 적응하는 반복적인 알고리즘을 가능하게 하는 반면, 배치 모드는 많은 독립적인 회로를 동시에 실행하는 데 유용하다.
Qiskit Serverless.
Qiskit Serverless는 양자-고전 워크로드를 분산된 클라우드 네이티브 방식으로 실행할 수 있도록 하는 Qiskit 생태계의 확장이다. 이는 원격 서버에서 컴퓨팅 리소스를 관리하고 양자 워크플로우의 일부를 실행하기 위한 간단한 인터페이스를 제공하여, 사용자가 양자 프로그램과 그에 수반되는 고전 처리 단계를 IBM Quantum 클라우드 또는 심지어 여러 클라우드 환경에 배포할 수 있도록 효과적으로 허용한다. Qiskit Serverless의 목표는 필요에 따라 양자 처리 장치와 고전 컴퓨팅 리소스의 할당을 모두 처리하여 유틸리티 규모의 양자 애플리케이션을 용이하게 하는 것이며, 이는 하이브리드 알고리즘 및 대규모 실험에 특히 유용하다. Qiskit Serverless는 다음을 위해 사용될 수 있다:
클라우드 리소스 관리의 세부 사항을 추상화함으로써 Qiskit Serverless는 양자 실험을 확장하고 이를 더 큰 컴퓨팅 워크플로우에 통합하는 것을 더 쉽게 만드는 것을 목표로 한다.
Qiskit Add-ons.
Qiskit Add-ons (Qiskit addons로 표기)는 양자 알고리즘 개발을 위한 Qiskit의 기능을 확장하도록 설계된 모듈식의 별도로 설치되는 도구이다. 이들은 Qiskit의 핵심 프레임워크를 기반으로 구축되며, 사용자의 워크플로우에 연결되어 새로운 알고리즘을 확장하거나 설계하는 데 도움을 줄 수 있다. 각 애드온은 독립적인 파이썬 패키지(예: SQD 도구를 위한 qiskit-addon-sqd)로 배포되며, 이는 파이썬 패키지 색인(PyPI)을 통해 설치한 다음 Qiskit SDK와 함께 사용할 수 있다. 이러한 공식 애드온은 회로 매핑, 최적화 및 결과 후처리(post‑processing)와 같은 작업을 향상시키면서 Qiskit의 기능과 완벽하게 통합된다.
각 애드온은 깃허브 Qiskit 조직에서 오픈 소스 확장으로 유지 관리되며, IBM Quantum에서 문서 및 튜토리얼을 제공한다. 이 모듈식 접근 방식은 연구원들이 필요에 따라 고급 알고리즘 기술을 선택할 수 있도록 하여, Qiskit의 핵심은 가볍게 유지하면서도 애드온을 통해 최첨단 기능을 가능하게 한다.
Qiskit Ecosystem.
Qiskit 생태계는 핵심 SDK의 일부가 아니면서 Qiskit과 인터페이스하는 더 넓은 오픈 소스 프로젝트 모음을 지칭한다. IBM Quantum 또는 더 넓은 커뮤니티에서 개발된 이러한 프로젝트는 Qiskit 프레임워크를 보완하는 추가 기능 및 특수 도구를 제공한다. IBM은 모듈식 및 확장 가능한 아키텍처로 Qiskit을 설계함으로써, 외부 패키지가 시뮬레이션, 작업 관리 및 오류 완화와 같은 영역에서 쉽게 통합되고 기능을 확장할 수 있도록 했다. 이 생태계는 기본 라이브러리의 범위를 넘어선 작업을 해결함으로써 Qiskit의 유용성을 향상시키며, 사용자가 커뮤니티 중심 솔루션으로 양자 컴퓨팅 워크플로우를 맞춤화할 수 있도록 한다. Qiskit 생태계의 주목할 만한 프로젝트는 다음과 같다:
이러한 생태계 프로젝트를 통해 Qiskit 사용자는 핵심 SDK에 포함되지 않은 확장된 기능에 접근하여 연구 및 애플리케이션 개발을 향상시킬 수 있다. 예를 들어, Aer는 시뮬레이션에서 알고리즘의 철저한 테스트를 가능하게 하고, qBraid는 다양한 클라우드 하드웨어에서 Qiskit 프로그램을 실행하는 것을 용이하게 하며, mthree는 더 정확한 실험 데이터를 얻는 데 도움을 준다. Qiskit 생태계 프로젝트의 포괄적인 카탈로그는 Qiskit Ecosystem 페이지에서 확인할 수 있으며, 사용자는 Qiskit과 함께 작동하는 다른 도구 및 라이브러리를 발견하고 심지어 자신의 것을 기여할 수도 있다. 이러한 모든 생태계 노력은 Qiskit을 중심으로 하는 더 다재다능하고 견고한 양자 컴퓨팅 툴킷에 기여한다.
Acme는 벨 연구소 플랜 9 운영체제의 문서 편집기이자 그래픽 셸이며, 롭 파이크가 설계하고 구현했다. Sam 명령어를 사용할 수 있다. 인터페이스 디자인은 오베론의 영향을 받았다. 9P 서버로 작동한다는 점에서 다른 편집 환경과 다르다. 사용자 인터페이스의 독특한 요소는 마우스 코드이다.
Acme는 메일 및 뉴스 리더 또는 wikifs의 프론트엔드로 사용할 수 있다. 이러한 응용 프로그램은 파일 시스템 인터페이스를 통해 acme와 상호 작용하는 외부 구성 요소로 인해 가능하다. 롭 파이크는 "Acme"라는 이름이 타임스 스퀘어에서 영화를 보던 중 펜 &amp; 텔러의 펜 질렛이 "모든 것을" 수행하는 문서 편집기에 적합한 이름을 물었을 때 그에게 제안했다고 언급했다.
인페르노 운영체제용 포트는 인페르노의 기본 배포판에 포함되어 있다. 인페르노는 다른 운영체제 위에서 응용 프로그램으로 실행될 수 있으므로 인페르노의 acme 포트는 마이크로소프트 윈도우 및 리눅스를 포함한 대부분의 운영체제에서 사용할 수 있다. acme: stand alone complex라는 프로젝트는 acme를 호스트 운영체제에서 독립 실행형 응용 프로그램으로 실행하도록 의도하고 있다.
유닉스 계열 운영체제용 acme의 작동 포트는 Plan 9 from User Space에 포함되어 있으며, 이는 플랜 9에서 포팅된 다양한 프로그램 모음이다. 현재 다음을 포함한 다양한 운영체제에서 테스트되었다. 리눅스, Mac OS X, FreeBSD, NetBSD, OpenBSD, 솔라리스 및 썬OS.
분자 질의 언어(Molecular Query Language, MQL)는 화학정보학에서 더 복잡하고 문제별 검색 방법을 허용하도록 설계되었다. 널리 사용되는 SMARTS 질의와 달리 MQL은 원자와 결합의 공간적 및 물리화학적 특성을 지정할 수 있다. 또한, "축소된 특성" 그래프로도 알려진 비원자 기반 그래프를 처리하도록 쉽게 확장될 수 있다.
이 질의 언어는 확장 백쿠스-나우어 형식(자바CC)을 기반으로 한다.
소프트웨어 공학과 시스템 공학에서 기능 요구사항(Functional requirement)은 시스템 또는 그 구성 요소의 기능을 정의하며, 이 기능은 입력과 출력 사이의 동작에 대한 요약(또는 명세나 진술)으로 기술된다.
기능 요구사항에는 계산, 기술적 세부사항, 데이터 조작 및 처리, 그리고 시스템이 수행해야 할 기타 특정 기능이 포함될 수 있다. 동작 요구사항은 시스템이 기능 요구사항을 사용하는 모든 경우를 설명하며, 이는 유스 케이스에 기록된다. 기능 요구사항은 "품질 요구사항"으로도 알려진 비기능 요구사항에 의해 뒷받침되며, 이는 설계 또는 구현에 제약(예: 성능 요구사항, 보안 또는 신뢰성)을 가한다. 일반적으로 기능 요구사항은 "시스템은 &lt;요구사항&gt;을 수행해야 한다"는 형식으로 표현되는 반면, 비기능 요구사항은 "시스템은 &lt;요구사항&gt;이 되어야 한다"는 형식을 취한다. 기능 요구사항 구현 계획은 시스템 설계에 상세히 기술되고, 비기능 요구사항은 시스템 아키텍처에 상세히 기술된다.
요구공학에서 정의된 바와 같이, 기능 요구사항은 시스템의 특정 결과를 명시한다. 이는 비용 및 신뢰성과 같은 전반적인 특성을 명시하는 비기능 요구사항과 대조된다. 기능 요구사항은 시스템의 애플리케이션 아키텍처를 주도하는 반면, 비기능 요구사항은 시스템의 기술 아키텍처를 주도한다.
어떤 경우에는 요구사항 분석가가 기능 요구사항 집합을 수집하고 검증한 후 유스 케이스를 생성한다. 기능 요구사항 수집 및 변경의 계층은 광범위하게 말하면 다음과 같다: 사용자/이해관계자 요청 → 분석 → 유스 케이스 → 통합. 이해관계자는 요청을 하고, 시스템 엔지니어는 요구사항의 측면을 논의하고 관찰하며 이해하려고 시도하고, 유스 케이스, 개체 관계 다이어그램 및 기타 모델이 요구사항을 검증하기 위해 구축되며, 문서화되고 승인되면 요구사항이 구현/통합된다. 각 유스 케이스는 하나 이상의 기능 요구사항을 통해 동작 시나리오를 보여준다. 그러나 분석가는 종종 유스 케이스 집합을 도출하는 것으로 시작하며, 이를 통해 분석가는 사용자가 각 유스 케이스를 수행할 수 있도록 구현해야 하는 기능 요구사항을 도출할 수 있다.
일반적인 기능 요구사항은 고유한 이름과 번호, 간략한 요약 및 근거를 포함한다. 이 정보는 독자가 요구사항이 왜 필요한지 이해하고 시스템 개발 과정에서 요구사항을 추적하는 데 도움이 된다. 요구사항의 핵심은 명확하고 읽기 쉬워야 하는 필수 동작에 대한 설명이다. 설명된 동작은 조직 또는 비즈니스 규칙에서 비롯될 수도 있고, 사용자, 이해관계자 및 조직 내 다른 전문가와의 도출 세션을 통해 발견될 수도 있다. 많은 요구사항이 유스 케이스 개발 중에 발견될 수 있다. 이 경우 요구사항 분석가는 이름과 요약을 포함하는 임시 요구사항을 생성하고, 나중에 더 잘 알려지면 채워질 세부 사항을 연구할 수 있다.
컴퓨팅 및 시스템 설계에서 느슨하게 결합된(loosely coupled) 시스템은 다음 중 하나이다.
느슨하게 결합된 시스템의 구성 요소는 동일한 서비스를 제공하는 대체 구현으로 교체될 수 있다. 느슨하게 결합된 시스템의 구성 요소는 동일한 플랫폼, 언어, 운영체제, 또는 빌드 환경에 덜 구속된다.
시스템이 시간적으로 분리되면 트랜잭션 무결성을 함께 제공하기 어렵고, 추가적인 조정 프로토콜이 필요하다. 다른 시스템 간의 데이터 복제는 느슨한 결합(가용성 측면)을 제공하지만, 일관성 유지에 문제를 야기한다.
통합에서.
더 넓은 분산 시스템 설계에서 느슨한 결합은 트랜잭션, 메시지 지향 미들웨어가 제공하는 큐, 그리고 상호 운용성 표준을 사용하여 달성된다.
느슨한 결합을 촉진하는 네 가지 유형의 자율성은 참조 자율성, 시간 자율성, 형식 자율성 및 플랫폼 자율성이다.
느슨한 결합은 서비스 지향 아키텍처의 아키텍처 원칙이자 설계 목표이다. 느슨한 결합의 11가지 형태와 그에 대응하는 강한 결합은 다음과 같다:
엔터프라이즈 서비스 버스(ESB) 미들웨어는 여러 차원에서 느슨한 결합을 달성하기 위해 발명되었다. 그러나 과도하게 설계되거나 잘못 배치된 ESB는 오히려 원치 않는 강한 결합과 중앙 집중형 아키텍처 핫스팟을 만들어낼 수도 있다.
이벤트 기반 아키텍처도 느슨한 결합을 촉진하는 것을 목표로 한다.
결합 감소 방법.
인터페이스의 느슨한 결합은 표준 형식(예: XML 또는 JSON)으로 데이터를 게시함으로써 향상될 수 있다.
프로그램 구성 요소 간의 느슨한 결합은 매개변수에 표준 데이터 유형을 사용함으로써 향상될 수 있다. 사용자 지정 데이터 유형이나 객체를 전달하려면 두 구성 요소가 사용자 지정 데이터 정의를 알아야 한다.
서비스의 느슨한 결합은 서비스에 전달되는 정보를 핵심 데이터로 줄임으로써 향상될 수 있다. 예를 들어, 편지를 보내는 서비스는 고객 식별자만 전달하고 고객 주소는 서비스 내에서 얻을 때 가장 재사용성이 높다. 이렇게 하면 서비스가 특정 순서(예: GetCustomerAddress, SendLetter)로 호출될 필요가 없어 서비스가 분리된다.
결합은 한 구성 요소가 다른 구성 요소에 대해 직접적으로 아는 정도를 나타낸다. 컴퓨팅에서 느슨한 결합은 비캡슐화와 대비되는 캡슐화로 해석된다.
강한 결합의 예는 의존적인 클래스가 필요한 동작을 제공하는 구체적인 클래스에 직접 포인터를 포함하는 경우이다. 이 의존성은 의존적인 클래스를 변경하지 않고는 대체되거나 "서명"이 변경될 수 없다. 느슨한 결합은 의존적인 클래스가 인터페이스에만 포인터를 포함하고, 이 인터페이스는 하나 또는 여러 구체적인 클래스에 의해 구현될 수 있을 때 발생한다. 이를 의존성 역전이라고 한다. 의존적인 클래스의 의존성은 인터페이스에 의해 지정된 "계약"에 있으며, 이는 구현 클래스가 제공해야 하는 메서드 및 속성의 정의된 목록이다. 따라서 인터페이스를 구현하는 모든 클래스는 해당 클래스를 변경할 필요 없이 의존적인 클래스의 의존성을 충족시킬 수 있다. 이는 소프트웨어 설계에서 확장성을 허용한다. 인터페이스를 구현하는 새로운 클래스는 종속 클래스를 변경할 필요 없이 일부 또는 모든 상황에서 현재 종속성을 대체하도록 작성될 수 있다. 새로운 클래스와 이전 클래스는 자유롭게 교환될 수 있다. 강한 결합은 이를 허용하지 않는다.
다음은 의존적 클래스와 필요한 동작을 제공하는 구체적 클래스 집합 간의 느슨한 결합을 보여주는 UML 다이어그램이다.
비교를 위해, 이 다이어그램은 의존적 클래스와 제공자 간의 강한 결합을 가진 대체 설계를 보여준다.
함수를 핵심 모듈로 삼거나(참고: 함수형 프로그래밍) 함수를 객체로 삼는 개념을 가진 컴퓨터 프로그래밍 언어는 느슨하게 결합된 프로그래밍의 훌륭한 예시를 제공한다. 함수형 언어는 Continuation, 클로저 또는 생성자 패턴을 가지고 있다. 클로저 및 리스프를 함수형 프로그래밍 언어의 예시로 보라. 스몰토크 및 루비와 같은 객체 지향 언어는 코드 블록을 가지고 있으며, 에펠은 에이전트를 가지고 있다. 기본 아이디어는 다른 어떤 둘러싸는 개념(예: 객체 함수를 둘러싸는 객체에 대한 직접적인 지식으로부터 분리)과 독립적으로 함수를 객체화(객체로 캡슐화)하는 것이다. 함수를 객체로 이해하는 더 깊은 통찰력을 얻으려면 일급 함수를 보라. 이것은 일급 함수의 한 형태이다.
예를 들어, 객체 지향 언어에서 객체의 함수가 객체로 참조될 때(둘러싸는 호스트 객체에 대한 지식으로부터 자유롭게) 새로운 함수 객체는 전달, 저장 및 나중에 호출될 수 있다. 이 함수 객체를 받은 객체는 둘러싸는 호스트 객체에 대한 직접적인 지식 없이도 자신에게 편리한 시간에 포함된 함수를 안전하게 실행(호출)할 수 있다. 이러한 방식으로 프로그램은 함수 객체의 체인 또는 그룹을 실행할 수 있으며, 둘러싸는 호스트 객체에 대한 직접적인 참조로부터 안전하게 분리될 수 있다.
전화번호는 훌륭한 비유이며 이러한 분리 정도를 쉽게 설명할 수 있다.
예를 들어, 어떤 개체가 다른 개체에게 특정 작업을 수행하도록 전화번호를 제공한다. 전화가 걸려오면 발신 개체는 효과적으로 "이 작업을 저를 위해 해주세요."라고 말하는 것이다. 분리 또는 느슨한 결합은 즉시 명확해진다. 전화번호를 받는 개체는 전화번호가 어디서 왔는지(예: 번호 제공자에 대한 참조) 알지 못할 수 있다. 반대로, 발신자는 자신이 누구에게 전화를 거는지, 그들이 어디에 있는지, 수신자가 내부적으로 어떻게 작동하는지에 대한 특정 지식으로부터 분리된다.
예를 한 단계 더 나아가면, 발신자는 수신자에게 "이 작업을 저를 위해 해주세요. 끝나면 이 번호로 다시 전화해주세요."라고 말할 수 있다. 수신자에게 제공되는 '번호'를 "콜백"이라고 한다. 다시 말하지만, 이 함수 객체의 느슨한 결합 또는 분리된 특성은 분명하다. 콜백의 수신자는 무엇 또는 누구에게 전화가 걸리는지 알지 못한다. 단순히 전화를 걸 수 있다는 것만 알고 언제 전화할지는 스스로 결정한다. 실제로는 콜백이 처음에 콜백을 제공한 사람에게 조차 아닐 수도 있다. 이러한 간접성은 함수 객체를 느슨하게 결합된 프로그램을 달성하기 위한 훌륭한 기술로 만드는 이유이다.
느슨하게 결합된 구성 요소 간의 통신은 언급된 비동기 통신 방식 또는 동기 메시지 전달 방식과 같은 다양한 메커니즘을 기반으로 할 수 있다.
데이터 요소 결합 측정.
느슨한 결합의 정도는 송신 또는 수신 시스템에서 발생할 수 있는 데이터 요소 변경 횟수를 기록하고 컴퓨터가 여전히 올바르게 통신할 수 있는지 판단함으로써 측정할 수 있다. 이러한 변경에는 다음과 같은 항목이 포함된다.
시스템 공학, 소프트웨어 공학, 기업공학에서 뷰 모델(view model) 또는 뷰포인트 프레임워크(viewpoints framework)는 시스템 아키텍처, 소프트웨어 구조 또는 엔터프라이즈 아키텍처 구축에 사용될 일관된 뷰 집합을 정의하는 프레임워크이다. 뷰는 관련 문제 집합의 관점에서 전체 시스템을 나타낸 것이다.
1990년대 초반부터 시스템 아키텍처를 설명하고 분석하는 접근 방식을 규정하려는 많은 노력이 있었다. 이러한 노력의 결과는 뷰(또는 뷰포인트) 집합을 정의하는 것이었다. 이러한 것들은 때때로 아키텍처 프레임워크 또는 엔터프라이즈 아키텍처 프레임워크라고도 불리지만, 일반적으로 "뷰 모델"이라고 불린다.
일반적으로 뷰는 특정 시스템에 대한 특정 아키텍처 데이터를 제시하는 작업 산출물이다. 그러나 동일한 용어가 때로는 특정 뷰포인트와 각 구체적인 뷰를 정의하는 해당 지침을 포함하는 뷰 정의를 참조하는 데 사용되기도 한다. 뷰 모델이라는 용어는 뷰 정의와 관련이 있다.
뷰와 뷰포인트의 목적은 인간이 매우 복잡계를 이해하고, 전문성 영역을 중심으로 문제와 해결책의 요소를 조직하고, 관심사를 분리하는 것이다. 물리적으로 집중적인 시스템의 공학에서 뷰포인트는 종종 공학 조직 내의 역량 및 책임과 일치한다.
대부분의 복잡한 시스템 명세는 너무 광범위하여 한 개인이 명세의 모든 측면을 완전히 이해할 수 없다. 또한, 우리는 주어진 시스템에 대해 서로 다른 관심사를 가지고 있으며 시스템의 명세를 검토하는 이유도 다르다. 사업 임원은 시스템 구현자보다 시스템 구성에 대해 다른 질문을 할 것이다. 따라서 뷰포인트 프레임워크의 개념은 이해관계자와의 의사소통을 용이하게 하기 위해 주어진 복잡한 시스템의 명세에 대한 개별적인 뷰포인트를 제공하는 것이다. 각 뷰포인트는 시스템의 특정 측면에 관심을 가진 청중을 만족시킨다. 각 뷰포인트는 해당 뷰포인트의 청중을 위해 어휘와 표현을 최적화하는 특정 뷰포인트 언어를 사용할 수 있다. 뷰포인트 모델링은 대규모 분산 시스템의 고유한 복잡성을 다루는 효과적인 접근 방식이 되었다.
IEEE Std 1471-2000에 설명된 아키텍처 설명 관행은 여러 관심 영역을 다루기 위해 여러 뷰를 사용하며, 각 뷰는 시스템의 특정 측면에 중점을 둔다. 여러 뷰를 사용하는 아키텍처 프레임워크의 예로는 크룩텐의 "4+1" 뷰 모델, 자크만 프레임워크, TOGAF, DoDAF, RM-ODP가 있다.
1970년대에 소프트웨어 공학에서 여러 뷰를 사용하여 모델링하는 방법이 등장하기 시작했다. 더글러스 T. 로스와 K.E. 쇼먼은 1977년에 시스템 요구사항 정의에서 모델링 프로세스를 조직하기 위해 컨텍스트, 뷰포인트, 시점 구성을 도입했다. 로스와 쇼먼에 따르면, 뷰포인트는 "[모델의] 전체 목적을 달성하는 데 관련 있다고 간주되는 측면을 명확히 하고" "[모델링되는 대상]을 어떻게 볼 것인가"를 결정한다.
뷰포인트의 예로는 기술적, 운영적, 경제적 뷰포인트가 제시된다. 1992년, 앤서니 핀켈스타인 외 다수는 뷰포인트에 관한 매우 중요한 논문을 발표했다. 이 연구에서: "뷰포인트는 개발 프로세스에서 '행위자', '지식 출처', '역할' 또는 '에이전트'라는 개념과 행위자가 유지하는 '뷰' 또는 '관점'이라는 개념의 조합으로 생각할 수 있다." 이 논문의 중요한 아이디어는 "뷰포인트가 볼 수 있는 것을 표현하는 방식, 스키마 및 표기법인 표현 스타일"과 "뷰포인트의 스타일로 특정 도메인을 설명하는 진술인 명세"를 구별하는 것이었다. IEEE 1471과 같은 후속 작업은 각각 뷰포인트와 뷰라는 두 개의 별도 용어를 사용하여 이러한 구별을 유지했다.
1990년대 초반부터 시스템 아키텍처를 설명하고 분석하는 접근 방식을 체계화하려는 여러 노력이 있었다. 이러한 것들은 종종 아키텍처 프레임워크 또는 때로는 뷰포인트 집합이라고 불린다. 이들 중 다수는 미국 국방부의 자금 지원을 받았지만, 일부는 ISO 또는 IEEE의 국제적 또는 국가적 노력에서 비롯되었다. 이들 중, 소프트웨어 집중 시스템의 아키텍처 설명에 대한 IEEE 권장 실무 지침(IEEE Std 1471-2000)은 뷰, 뷰포인트, 이해관계자 및 관심사의 유용한 정의와 이해관계자 관심사를 다루기 위해 뷰포인트를 적용하여 여러 뷰를 사용하여 시스템 아키텍처를 문서화하는 지침을 수립했다. 여러 뷰를 사용하는 이점은 숨겨진 요구사항과 이해관계자 간의 불일치를 더 쉽게 발견할 수 있다는 것이다. 그러나 연구에 따르면 실제로는 여러 뷰를 조정하는 추가 복잡성이 이러한 이점을 약화시킬 수 있다.
IEEE 1471 (현재 ISO/IEC/IEEE 42010:2011, 시스템 및 소프트웨어 공학 — 아키텍처 설명)은 아키텍처 설명의 내용을 규정하고, 전례 있는/없는 설계, 진화적 설계, 기존 시스템의 설계 캡처를 포함한 여러 시나리오에서 이들의 생성 및 사용을 설명한다. 이 모든 시나리오에서 전체 프로세스는 동일하다: 이해관계자를 식별하고, 관심사를 도출하고, 사용될 뷰포인트 집합을 식별한 다음, 이러한 뷰포인트 명세를 적용하여 관심 시스템과 관련된 뷰 집합을 개발한다. 특정 뷰포인트 집합을 정의하는 대신, 이 표준은 아키텍트와 조직이 자체 뷰포인트를 정의하기 위한 균일한 메커니즘과 요구사항을 제공한다. 1996년에 분산 처리 참조 모델(RM-ODP) ISO가 대규모 분산 시스템의 아키텍처 및 설계를 설명하는 데 유용한 프레임워크를 제공하기 위해 발표되었다.
뷰 모델 주제.
시스템의 뷰는 뷰포인트의 관점에서 시스템을 나타낸 것이다. 시스템에 대한 이 뷰포인트는 시스템에 관한 특정 관심사에 초점을 맞추는 관점을 포함하며, 뷰포인트의 관심사와 관련된 요소만 포함하는 단순화된 모델을 제공하기 위해 세부 사항을 숨긴다. 예를 들어, 보안 뷰포인트는 보안 관심사에 초점을 맞추고, 보안 뷰포인트 모델은 시스템의 더 일반적인 모델에서 보안과 관련된 요소를 포함한다.
뷰는 사용자가 특정 관심 영역의 일부를 검사할 수 있도록 한다. 예를 들어, 정보 뷰는 특정 정보 조각을 사용하는 모든 기능, 조직, 기술 등을 제시할 수 있는 반면, 조직 뷰는 특정 조직과 관련된 모든 기능, 기술 및 정보를 제시할 수 있다. 자크만 프레임워크에서 뷰는 개발에 특정 분석 및 기술 전문 지식이 필요한 작업 산출물 그룹을 포함한다. 이는 기업의 "무엇," "어떻게," "누가," "어디서," "언제," 또는 "왜"에 초점을 맞추기 때문이다. 예를 들어, 기능 뷰 작업 산출물은 "임무는 어떻게 수행되는가?"라는 질문에 답한다. 이러한 작업 산출물은 프로세스 및 활동 모델링을 사용하는 기능 분해 전문가가 가장 쉽게 개발할 수 있다. 이들은 기능의 관점에서 기업을 보여준다. 또한 조직 및 정보 구성 요소를 보여줄 수도 있지만, 기능과 관련될 때만 보여준다.
뷰포인트.
시스템 공학에서 뷰포인트는 시스템 내 관심사의 분할 또는 제한이다. 뷰포인트를 채택하는 것은 해당 측면의 문제를 별도로 다룰 수 있도록 유용하다. 뷰포인트를 잘 선택하면 시스템 설계가 특정 전문 분야로 분할되기도 한다.
뷰포인트는 뷰를 구성하고 제시하며 분석하기 위한 규칙, 규약 및 언어를 제공한다. ISO/IEC 42010:2007(IEEE-Std-1471-2000)에서 뷰포인트는 개별 뷰에 대한 명세이다. 뷰는 뷰포인트의 관점에서 전체 시스템을 나타낸 것이다. 뷰는 하나 이상의 아키텍처 모델로 구성될 수 있다. 각 아키텍처 모델은 관련 아키텍처 시스템과 전체 시스템에 의해 설정된 방법을 사용하여 개발된다.
모델링 관점.
모델링 관점은 시스템의 미리 선택된 측면을 표현하는 다양한 방식의 집합이다. 각 관점은 모델이 나타내는 것에 대해 다른 초점, 개념화, 전념 및 시각화를 가지고 있다.
정보 시스템에서 모델링 관점을 나누는 전통적인 방법은 구조적, 기능적, 행동/프로세스적 관점을 구별하는 것이다. 이는 규칙, 객체, 통신, 행위자 및 역할 관점과 함께 모델링 접근 방식을 분류하는 한 가지 방법이다.
뷰포인트 모델.
주어진 뷰포인트에서 해당 뷰포인트에서 보이는 객체만 포함하지만 시스템에 존재하고 해당 뷰포인트와 관련된 모든 객체, 관계 및 제약 조건을 캡처하는 시스템 모델을 만드는 것이 가능하다. 이러한 모델을 뷰포인트 모델 또는 해당 뷰포인트에서 본 시스템의 뷰라고 한다.
주어진 뷰는 특정 뷰포인트에서 특정 추상화 수준의 시스템에 대한 명세이다. 추상화 수준이 다르면 세부 수준도 다르다. 상위 수준 뷰는 엔지니어가 전체 설계를 구상하고 이해하며 큰 문제점을 식별하고 해결할 수 있도록 한다. 하위 수준 뷰는 엔지니어가 설계의 일부에 집중하고 상세 명세를 개발할 수 있도록 한다.
그러나 시스템 자체에서 다양한 뷰포인트 모델에 나타나는 모든 명세는 시스템의 실제 구성 요소에서 다루어져야 한다. 그리고 주어진 구성 요소에 대한 명세는 여러 다른 뷰포인트에서 가져올 수 있다. 반면에, 특정 구성 요소 및 구성 요소 상호 작용에 걸친 기능 분배에 의해 유도된 명세는 일반적으로 원래 뷰포인트에 반영된 것과는 다른 관심사 분할을 반영할 것이다. 따라서 개별 구성 요소 및 시스템의 상향식 합성에 대한 관심사를 다루는 추가 뷰포인트도 유용할 수 있다.
아키텍처 설명.
아키텍처 설명은 구성 요소, 해당 구성 요소의 작동 방식, 해당 구성 요소가 작동하는 규칙 및 제약 조건, 해당 구성 요소가 서로 및 환경과 어떻게 관련되는지에 대한 시스템 아키텍처의 표현이다. 아키텍처 설명에서 아키텍처 데이터는 여러 뷰 및 제품에 걸쳐 공유된다.
데이터 계층에는 아키텍처 데이터 요소와 해당 정의 속성 및 관계가 있다. 프레젠테이션 계층에는 아키텍처의 목적, 설명하는 내용, 수행된 다양한 아키텍처 분석을 시각적으로 전달하고 이해하는 데 도움이 되는 제품 및 뷰가 있다. 제품은 아키텍처 데이터를 그래픽, 표 또는 텍스트 형식으로 시각화하는 방법을 제공한다. 뷰는 제품 전반에 걸쳐 아키텍처 데이터를 시각화하고, 아키텍처의 특정 또는 전체적인 관점을 위해 데이터를 논리적으로 구성하는 기능을 제공한다.
시스템 뷰 모델의 유형.
3-스키마 접근 방식.
1977년에 도입된 3-스키마 접근 방식은 데이터 모델링을 위한 최초의 뷰 모델 중 하나로 간주될 수 있다. 이는 개념 모형을 데이터 통합을 달성하기 위한 핵심으로 홍보하는 정보 시스템 및 시스템 정보 관리를 구축하는 접근 방식이다. 3-스키마 접근 방식은 세 가지 스키마와 뷰를 정의한다.
중심에서 개념 스키마는 사용자가 생각하고 이야기하는 방식대로 개념의 온톨로지를 정의한다. 물리적 스키마는 데이터베이스에 저장된 데이터의 내부 형식을 설명하고, 외부 스키마는 애플리케이션 프로그램에 제시되는 데이터의 뷰를 정의한다. 이 프레임워크는 외부 스키마에 여러 데이터 모델을 사용할 수 있도록 시도했다.
수년에 걸쳐 정보 시스템 구축에 대한 기술과 관심은 엄청나게 성장했다. 그러나 대부분의 경우 시스템 구축에 대한 전통적인 접근 방식은 "사용자 뷰"와 "컴퓨터 뷰"라는 두 가지 뚜렷한 뷰에서 데이터를 정의하는 데만 중점을 두었다. "외부 스키마"라고 불리는 사용자 뷰에서 데이터의 정의는 개인이 특정 작업을 수행하는 데 도움이 되도록 설계된 보고서 및 화면의 맥락에서 이루어진다. 사용량 뷰에서 데이터의 필수 구조는 비즈니스 환경과 사용자의 개별 선호도에 따라 변경된다. "내부 스키마"라고 불리는 컴퓨터 뷰에서 데이터는 저장 및 검색을 위한 파일 구조 측면에서 정의된다. 컴퓨터 저장을 위한 데이터의 필수 구조는 사용된 특정 컴퓨터 기술과 데이터의 효율적인 처리에 대한 필요성에 따라 달라진다.
4+1 아키텍처 뷰 모델.
4+1은 1995년 필립 크룩텐이 여러 동시 뷰를 기반으로 소프트웨어 집중 시스템의 아키텍처를 설명하기 위해 설계한 뷰 모델이다. 뷰는 최종 사용자, 개발자 및 프로젝트 관리자와 같은 다양한 이해관계자의 관점에서 시스템을 설명하는 데 사용된다. 모델의 네 가지 뷰는 논리적, 개발, 프로세스 및 물리적 뷰이다.
모델의 네 가지 뷰는 다음을 다룬다.
또한 선택된 유스 케이스 또는 시나리오는 아키텍처를 설명하는 데 활용된다. 따라서 모델은 4+1 뷰를 포함한다.
엔터프라이즈 아키텍처 뷰의 종류.
엔터프라이즈 아키텍처 프레임워크는 엔터프라이즈 아키텍처와 관련된 구조와 뷰를 구성하는 방법을 정의한다. 엔터프라이즈 아키텍처 및 공학 분야가 매우 광범위하고, 기업이 크고 복잡할 수 있기 때문에, 해당 분야와 관련된 모델 또한 크고 복잡한 경향이 있다. 이러한 규모와 복잡성을 관리하기 위해 아키텍처 프레임워크는 작업을 집중시키고 가장 필요할 때 가치 있는 산출물을 생산할 수 있는 도구와 방법을 제공한다.
아키텍처 프레임워크는 일반적으로 정보기술 및 정보 시스템 거버넌스에서 사용된다. 조직은 시스템 설계가 승인되기 전에 특정 모델이 생산되도록 의무화할 수 있다. 유사하게, 조달된 시스템의 문서화에 특정 뷰가 사용되도록 지정할 수 있다. 미 국방부는 특정 가치 이상의 자본 프로젝트에 대해 장비 공급업체가 특정 DoDAF 뷰를 제공하도록 규정하고 있다.
자크만 프레임워크.
1987년 IBM의 존 자크만이 처음 구상한 자크만 프레임워크는 기업을 보고 정의하는 공식적이고 고도로 구조화된 방식을 제공하는 엔터프라이즈 아키텍처를 위한 프레임워크이다.
이 프레임워크는 아키텍처 "산출물"을 누가 산출물을 대상으로 하는지(예: 비즈니스 소유자 및 구축자)와 어떤 특정 문제(예: 데이터 및 기능)를 다루는지 모두 고려하는 방식으로 구성하는 데 사용된다. 이러한 산출물에는 설계 문서, 명세 및 모델이 포함될 수 있다.
자크만 프레임워크는 엔터프라이즈 아키텍처의 기본 요소를 표현하는 표준 접근 방식으로 자주 언급된다. 자크만 프레임워크는 미국 연방 정부로부터 "...기업 및 이를 지원하는 시스템의 변화를 관리하기 위한 통합 프레임워크로 전 세계적으로 인정받았다"고 인정받았다.
RM-ODP 뷰.
국제 표준화 기구(ISO) 개방 분산 처리 참조 모델(RM-ODP)는 분산 소프트웨어/하드웨어 시스템의 설계를 분할하기 위한 뷰포인트 집합을 지정한다. 대부분의 통합 문제는 이러한 시스템의 설계 또는 매우 유사한 상황에서 발생하므로, 이러한 뷰포인트는 통합 문제를 분리하는 데 유용할 수 있다. RM-ODP 뷰포인트는 다음과 같다.
RM-ODP는 또한 뷰포인트 간 일관성 명세를 설계에 포함할 것을 요구한다.
DoDAF 뷰.
미국 국방부 아키텍처 프레임워크(DoDAF)는 엔터프라이즈 아키텍처(EA) 또는 시스템 아키텍처를 보완적이고 일관된 뷰로 구성하는 표준적인 방법을 정의한다. 복잡한 통합 및 상호 운용성 과제를 가진 대규모 시스템에 특히 적합하며, 개발 중인 시스템이 작동할 외부 고객의 운영 도메인을 상세히 설명하는 "운영 뷰"를 사용하는 데 있어 독특하다고 할 수 있다.
DoDAF는 그래픽, 표, 텍스트 수단을 통해 아키텍처 설명의 광범위한 범위와 복잡성을 시각화하고 이해하며 동화하는 메커니즘 역할을 하는 일련의 제품을 정의한다. 이 제품은 네 가지 뷰로 구성된다.
각 뷰는 아래 설명된 대로 아키텍처의 특정 관점을 나타낸다. 각 시스템 개발에는 전체 DoDAF 뷰셋의 하위 집합만 생성되는 것이 일반적이다. 이 그림은 운영 뷰, 시스템 및 서비스 뷰, 기술 표준 뷰를 연결하는 정보를 나타낸다. 세 가지 뷰와 이들의 상호 관계는 공통 아키텍처 데이터 요소에 의해 구동되며, 상호 운용성 또는 성능과 같은 측정값을 도출하고, 이러한 메트릭 값의 운영 임무 및 작업 효율성에 미치는 영향을 측정하는 기반을 제공한다.
연방 엔터프라이즈 아키텍처 뷰.
미국 연방 엔터프라이즈 아키텍처에서 엔터프라이즈, 세그먼트, 솔루션 아키텍처는 세부 수준을 다양화하고 관련되지만 구별되는 문제를 다룸으로써 다른 비즈니스 관점을 제공한다. 기업 자체가 계층적으로 조직된 것처럼, 각 아키텍처 유형이 제공하는 다양한 뷰도 계층적이다. 연방 엔터프라이즈 아키텍처 실무 지침(2006)은 세 가지 유형의 아키텍처를 정의했다.
정의에 따르면 엔터프라이즈 아키텍처(EA)는 전략, 비즈니스 프로세스, 투자, 데이터, 시스템 또는 기술 등 공통 또는 공유 자산을 식별하는 것과 근본적으로 관련된다. EA는 전략에 의해 주도되며, 기관이 자원을 기관 임무 및 전략적 목표에 적절하게 조정했는지 식별하는 데 도움이 된다. 투자 관점에서 EA는 IT 투자 포트폴리오 전체에 대한 의사 결정을 이끌어내는 데 사용된다. 따라서 EA의 주요 이해관계자는 기관이 임무를 가능한 한 효과적이고 효율적으로 수행하도록 보장하는 고위 관리자와 임원이다.
대조적으로, 세그먼트 아키텍처는 핵심 임무 영역, 비즈니스 서비스 또는 엔터프라이즈 서비스를 위한 간단한 로드맵을 정의한다. 세그먼트 아키텍처는 비즈니스 관리에 의해 주도되며 시민 및 기관 직원에 대한 서비스 제공을 개선하는 제품을 제공한다. 투자 관점에서 세그먼트 아키텍처는 핵심 임무 영역 또는 공통 또는 공유 서비스를 지원하는 비즈니스 사례 또는 비즈니스 사례 그룹에 대한 의사 결정을 이끌어낸다. 세그먼트 아키텍처의 주요 이해관계자는 비즈니스 소유자 및 관리자이다. 세그먼트 아키텍처는 구조, 재사용 및 정렬의 세 가지 원칙을 통해 EA와 관련된다. 첫째, 세그먼트 아키텍처는 EA에서 사용되는 프레임워크를 상속하지만, 핵심 임무 영역 또는 공통 또는 공유 서비스의 특정 요구 사항을 충족하도록 확장 및 전문화될 수 있다. 둘째, 세그먼트 아키텍처는 데이터, 공통 비즈니스 프로세스 및 투자, 애플리케이션 및 기술을 포함하여 엔터프라이즈 수준에서 정의된 중요한 자산을 재사용한다. 셋째, 세그먼트 아키텍처는 비즈니스 전략, 명령, 표준 및 성과 측정과 같이 엔터프라이즈 수준에서 정의된 요소와 정렬된다.
명목상 뷰 집합.
"우주 시스템 아키텍처 모델링을 위한 프레임워크"를 탐색하면서 피터 셰임즈와 조셉 스키퍼(2006)는 "명목상 뷰 집합"을 정의했다. CCSDS RASDS, RM-ODP, ISO 10746에서 파생되었으며 IEEE 1471을 준수한다.
아래 설명된 "뷰 집합"은 가능한 모델링 뷰포인트의 목록이다. 이 모든 뷰가 어떤 프로젝트에도 사용될 필요는 없으며, 필요에 따라 다른 뷰가 정의될 수 있다. 일부 분석에서는 여러 뷰포인트의 요소가 새로운 뷰로 결합될 수 있으며, 아마도 계층화된 표현을 사용할 수도 있다.
후반부 발표에서 이 명목상 뷰 집합은 확장된 RASDS 의미 정보 모델 파생으로 제시되었다. 여기서 RASDS는 우주 데이터 시스템을 위한 참조 아키텍처(Reference Architecture for Space Data Systems)를 의미한다. 두 번째 이미지를 참조하라.
이전에 나열된 뷰 모델과 달리, 이 "명목상 뷰 집합"은 광범위한 뷰를 나열하며, 일반적인 소프트웨어 집약적 시스템 아키텍처를 설명하기 위한 강력하고 확장 가능한 접근 방식을 개발할 수 있다.
컴퓨터 과학에서 임의 정밀도 연산(Arbitrary-precision arithmetic)은 큰 수 연산, 다중 정밀도 연산 또는 때로는 무한 정밀도 연산이라고도 불리며, 호스트 시스템의 가용 메모리에 의해서만 정밀도의 자릿수가 잠재적으로 제한되는 수에 대해 계산이 수행됨을 나타낸다. 이는 일반적으로 8비트에서 64비트의 정밀도를 제공하는 대부분의 산술 논리 장치(ALU) 하드웨어에서 발견되는 더 빠른 고정 소수점 연산과 대조된다.
여러 최신 프로그래밍 언어는 큰 수에 대한 내장 지원을 제공하며, 다른 언어는 임의 정밀도 정수형 및 부동소수점 연산을 위한 라이브러리를 사용할 수 있다. 이 구현들은 프로세서 레지스터 크기와 관련된 고정된 비트 수로 값을 저장하는 대신, 일반적으로 가변 길이 배열의 자릿수를 사용한다.
임의 정밀도는 산술 속도가 제한 요소가 아니거나 매우 큰 수에 대한 정확한 결과가 필요한 응용 분야에 사용된다. 이는 많은 컴퓨터 대수학 시스템에서 제공하는 심볼릭 연산과 혼동해서는 안 된다. 심볼릭 연산은 와 같은 표현식으로 숫자를 나타내며, 따라서 무한 정밀도로 모든 계산 가능한 수를 나타낼 수 있다.
일반적인 응용 분야는 공개 키 암호 방식이며, 그 알고리즘은 일반적으로 수백 자리의 정수 연산을 사용한다. 또 다른 분야는 인위적인 한계와 오버플로가 부적절한 상황이다. 또한 고정 정밀도 계산 결과를 확인하고, 예를 들어 가우스 적분에 나타나는 formula_1와 같은 공식에 필요한 계수의 최적 또는 거의 최적의 값을 결정하는 데 유용하다.
임의 정밀도 연산은 π과 같은 기본 수학 상수를 수백만 자리 이상으로 계산하고 자릿수 문자열의 특성을 분석하거나 더 일반적으로 특정 질문을 분석적 방법으로 탐색하기 어려운 리만 제타 함수와 같은 함수의 정확한 동작을 조사하는 데에도 사용된다. 또 다른 예는 망델브로 집합에서 볼 수 있는 것과 같이 극도로 높은 확대율로 프랙탈 이미지를 렌더링하는 경우이다.
임의 정밀도 연산은 고정 정밀도 연산의 본질적인 한계인 오버플로를 피하는 데에도 사용될 수 있다. 자동차의 오도미터 디스플레이가 99999에서 00000으로 바뀌는 것과 유사하게, 숫자가 너무 커서 고정된 정밀도 수준에서 표현할 수 없을 때 고정 정밀도 정수는 오버플로를 나타낼 수 있다. 일부 프로세서는 대신 포화를 통해 오버플로를 처리할 수 있다. 이는 결과가 표현할 수 없는 경우, 가장 가까운 표현 가능한 값으로 대체됨을 의미한다. (16비트 부호 없는 포화 연산에서는 65535에 양수 값을 더하면 65535가 된다.) 일부 프로세서는 산술 결과가 사용 가능한 정밀도를 초과할 경우 예외를 생성할 수 있다. 필요한 경우 예외를 포착하고 복구할 수 있다. 예를 들어, 임의 정밀도 연산을 사용하여 소프트웨어에서 연산을 다시 시작할 수 있다.
많은 경우, 태스크 또는 프로그래머는 특정 응용 프로그램의 정수 값이 오버플로를 일으킬 만큼 커지지 않을 것임을 보장할 수 있다. 이러한 보장은 실용적인 한계에 기반할 수 있다: 학교 출석 프로그램은 4,000명의 학생이라는 태스크 한계를 가질 수 있다. 프로그래머는 중간 결과가 지정된 정밀도 경계 내에 유지되도록 계산을 설계할 수 있다.
리스프, 파이썬, 펄, 하스켈, 루비, 라쿠와 같은 일부 프로그래밍 언어는 모든 정수 연산에 임의 정밀도 숫자를 사용하거나 사용할 수 있는 옵션이 있다. 이를 통해 정수는 시스템의 가용 메모리에 의해서만 제한되는 어떤 크기로든 커질 수 있다. 비록 이것이 성능을 저하시키지만, 단순한 오버플로로 인한 잘못된 결과(또는 예외)에 대한 우려를 없애준다. 또한 특정 시스템의 워드 크기에 관계없이 모든 기계에서 산술 결과가 동일함을 거의 보장할 수 있게 한다. 프로그래밍 언어에서 임의 정밀도 숫자만을 독점적으로 사용하는 것은 언어를 단순화시키는데, 숫자는 숫자이며 다른 정밀도 수준을 나타내기 위해 여러 유형이 필요 없기 때문이다.
구현 문제.
임의 정밀도 연산은 프로세서 레지스터에 완전히 맞는 숫자를 사용하는 연산보다 훨씬 느리다. 후자는 일반적으로 하드웨어 산술로 구현되는 반면, 전자는 소프트웨어로 구현되어야 하기 때문이다. 컴퓨터에 특정 연산(정수 나눗셈 또는 모든 부동 소수점 연산 등)을 위한 하드웨어가 부족하고 대신 소프트웨어가 제공되더라도, 이는 사용 가능한 하드웨어 레지스터와 밀접하게 관련된 숫자 크기, 즉 한두 워드만 사용한다. 1950년대와 1960년대의 특정 가변 워드 길이 컴퓨터들, 특히 IBM 1620, IBM 1401 및 하니웰 200 시리즈는 값의 경계를 나타내는 추가 비트와 함께 사용 가능한 저장 공간에 의해서만 제한되는 숫자를 조작할 수 있었다는 예외가 있다.
숫자는 고정 소수점 형식 또는 부동소수점 형식으로 임의의 지수를 곱한 유효 숫자로 저장될 수 있다. 그러나 나눗셈은 거의 즉시 무한 반복 자릿수 시퀀스(예: 십진법에서 4/7, 이진법에서 1/10)를 도입하므로, 이러한 가능성이 발생하면 표현이 만족스러운 크기에서 잘리거나 유리수가 사용된다. 즉, 분자와 분모에 큰 정수를 사용한다. 그러나 최대 공약수를 제거하더라도 유리수 연산은 매우 빠르게 다루기 어려워질 수 있다. 1/99 − 1/100 = 1/9900이고, 1/101을 더하면 결과는 10001/999900이다.
임의 정밀도 숫자의 크기는 실제로 사용 가능한 총 저장 공간과 계산 시간에 의해 제한된다.