OMG SysML 다이어그램 마스터하기::모델링 가이드

 

 시스템 설계에서 마주하는 수많은 복잡한 요구사항과 상호작용을

어떻게 명확하고 체계적으로 표현할 수 있을까?

프로젝트의 방대한 정보를 일관성 있게 문서화하고 소통하는 데 어려움을 겪고 있는 현실에서,

SysML 표기법은 이러한 기술적 의사소통 난관을 해결할 수 있는 핵심 솔루션입니다.

따라서 이 글에서는 시스템 모델링의 표준 언어인 SysML의 주요 표기법을 상세히 살펴보겠습니다.

 

 

1. 패키지 다이어그램 (SysML::Package Diagram)

Diagram Element	표기법	설명
Comment Node		• Comment Note는 모델 요소의 추가 정보 제공하거나 설명을 부연하는 데 사용되는 주석 요소 • 이는 특정 모델 요소와 연관되거나 독립적으로 사용될 수 있음 • 설계 의도, 제약사항, 가정, 또는 기타 중요한 정보를 기록하는 데 활용 • Comment Note는 다이어그램에 간단한 텍스트 형식으로 나타냄 • 화살표를 사용해 관련 요소와 연결할 수 있음 • 예를 들어, 특정 패키지에 대해 “이 패키지는 차량 제어 시스템의 모든 하위 요소를 포함합니다”라는 설명을 추가할 수 있습니다.
Package Node		• Package Node는 시스템 모델의 요소들을 논리적으로 그룹화하여 구성하고 관리하는 단위 • Package는 모델 요소의 조직화, 이름 공간 제공, 의존성 관리 등을 지원 • 복잡한 시스템 모델을 체계적으로 분류하는 데 활용할 수 있음 • Package 안에는 다른 Package나 다양한 모델 요소(예: Block, Diagram, Requirement 등)를 포함할 수 있음 • 계층적 구조를 통해 모듈성과 재사용성을 촉진 • 예를 들어, “차량 시스템” Package는 “파워트레인”, “차체”, “전자 제어”와 같은 하위 패키지를 포함하여 차량 설계를 체계적으로 분리할 수 있습니다.
Model Node		• Model Node는 시스템 모델링의 최상위 컨테이너로, 모델링 작업의 전체 범위를 포함하는 요소 • Model은 하나의 논리적 단위로 모든 Package, Diagram, Block 등을 포괄하며, 모델링 프로젝트의 최상위 구조를 정의 • 이는 시스템 설계와 분석을 위한 기준점을 제공하며, 모델의 목적, 범위, 주요 구성 요소를 명확히 나타냄 • 예를 들어, “자동차 설계 모델”이라는 Model Node는 차량 시스템과 관련된 모든 패키지와 다이어그램을 포함할 수 있습니다.
Packageable Element Node		• Packageable Element Node는 패키지에 포함될 수 있는 다양한 모델 요소를 나타냄 • 시스템 모델의 재사용성과 조직화를 지원하는 기본 단위 • 이 노드는 Block, Diagram, Interface, Constraint 등과 같이 모델 내에서 독립적으로 관리할 수 있는 요소를 포괄하며, 다른 패키지로 이동하거나 참조될 수 있는 특징을 가짐 • 예를 들어, “센서 모듈”이라는 Packageable Element는 특정 패키지에 포함되어 센서 관련 설계 요소를 정의하거나 다른 시스템 설계에 재사용될 수 있습니다.
View Node		• View Node는 모델의 특정 관점(viewpoint)을 정의 • 이해관계자나 특정 목적에 맞는 정보를 선택적으로 제공하는 요소 • View Node는 모델의 전체 내용을 보여주지 않고, 설계, 분석, 검증 등 특정 요구를 충족시키기 위해 중요한 부분만 필터링하거나 강조하여 표현 • 예를 들어, “안전 분석 View”는 시스템 모델 중 안전 관련 구성 요소와 제약 조건만을 포함하여 보여줄 수 있습니다.
Viewpoint Node		• Viewpoint Node는 특정 이해관계자나 목적에 따라 모델을 바라보는 관점을 정의 • Viewpoint는 어떤 정보를 포함하고 어떤 형식으로 표현할지에 대한 규칙과 지침을 제공 • View를 생성하는 기준을 설정 • 예를 들어, “보안 Viewpoint”는 시스템의 보안성을 분석하기 위해 어떤 구성 요소와 관계를 다룰지 명확히 정의할 수 있습니다.
Containment Path		• Containment Path는 모델 요소들 간의 포함 관계를 나타내며, 특정 Package가 다른 요소나 하위 Package를 포함하고 있음을 시각적으로 표현 • 이는 시스템 모델의 계층적 구조를 명확히 하며, 요소 간의 소유 관계를 보여주는 데 사용 • 다이어그램에서는 선으로 연결되어 있으며, 일반적으로 포함하는 Package에서 포함된 요소로 이어짐 • 예를 들어, “차량 시스템” Package에서 “엔진”, “차체”, “전자 제어” 등의 하위 요소를 포함하는 Containment Path를 통해 시스템의 구조를 체계적으로 보여줄 수 있습니다.
Import Path		• Import Path는 한 Package가 다른 Package나 모델 요소를 참조하거나 사용할 수 있도록 하는 관계를 나타냄 • Import Path는 모델 요소 간의 의존성을 정의하며, 참조된 요소를 재정의하거나 복제하지 않고 그대로 활용할 수 있게 함 • 다이어그램에서는 화살표로 표현되며, 화살표의 시작점이 참조하는 Package, 끝점이 참조되는 Package를 가리킴 • 예를 들어, “차량 시스템” Package가 “공통 유틸리티” Package를 Import Path로 참조하면, 공통 유틸리티의 요소를 차량 시스템에서 재사용할 수 있습니다.
Dependency Path		• Dependency Path는 한 모델 요소가 다른 요소에 의존함을 나타내는 관계를 표현 • Dependency Path는 요소 간의 의존성이나 영향을 시각적으로 보여주며, 다이어그램에서 점선 화살표로 표시됨 • 화살표는 의존하는 요소에서 의존되는 요소로 향합니다. • 예를 들어, “차량 설계” Package가 “엔진 구성” Package에 의존하는 Dependency Path는 차량 설계가 엔진 구성의 정의나 변경에 영향을 받을 수 있음을 나타냅니다.
Conform Path		• Conform Path는 특정 View가 정의된 Viewpoint를 따르고 있음을 나타내는 관계를 표현 • 이는 View가 해당 Viewpoint의 지침과 기준을 준수하여 생성되었음을 명시적으로 보여줌 • 다이어그램에서는 점선 화살표로 표시되며, 화살표는 View에서 Viewpoint를 향합니다. • 예를 들어, “안전 분석 View”가 “안전 Viewpoint”에 Conform Path로 연결되어 있다면, 해당 View가 안전성 분석의 요구사항과 규칙을 충족하도록 설계되었음을 나타냅니다.
Metamodel Node		• Metamodel Node는 모델링 작업의 구조와 규칙을 정의하는 상위 수준의 모델 • Metamodel은 모델 요소 간의 관계와 속성을 규정 • 특정 도메인이나 프레임워크에 맞는 모델링 언어를 정의/확장 • 예를 들어, “SysML 메타모델”은 SysML의 모든 요소(블록, 관계, 속성 등)와 그들 간의 상호작용을 설명합니다.
Metaclass Node		• Metaclass Node는 모델링 언어의 구조를 정의하는 메타모델의 구성 요소로, 특정 클래스나 요소의 유형(Type)을 나타냅니다. • Metaclass는 모델링 언어에서 사용되는 기본 개념(예: Block, Association, Constraint)을 정의 • 모델 요소가 어떤 속성과 동작을 가질 수 있는지를 규정 • 예를 들어, “Block” Metaclass는 SysML에서 Block의 속성, 관계, 동작을 정의하는 역할을 합니다.
Model Library Node		• Model Library Node는 재사용 가능한 모델 요소들의 집합을 정의하는 패키지로, 공통적으로 사용되는 요소나 템플릿을 저장하고 공유하는 데 사용 • Model Library는 일반적으로 표준화된 구성 요소, 인터페이스, 데이터 유형, 또는 설계 패턴을 포함 • 다른 모델에서 가져와 사용할 수 있도록 설계됨 • 예를 들어, “자동차 부품 라이브러리” Model Library는 엔진, 바퀴, 제어 시스템과 같은 표준 부품 정의를 포함하여 다양한 자동차 모델에서 재사용할 수 있습니다.
Stereotype Node		• Stereotype Node는 모델 요소에 사용자 정의 속성이나 의미를 추가하기 위해 사용하는 확장 메커니즘 • Stereotype은 SysML 또는 UML의 표준 메타모델을 확장하여 도메인별 요구사항을 충족하도록 모델링을 커스터마이징할 수 있음 • 이는 요소에 특정 속성(Properties)과 제약(Constraints)을 추가하며, << >> 구문으로 표현됩니다. • 예를 들어, “안전Critical”이라는 Stereotype은 시스템 내에서 안전과 관련된 요소를 식별하고, 해당 요소에 특정 속성을 부여하는 데 사용될 수 있습니다.
Profile Node		• Profile Node는 모델링 언어를 특정 도메인이나 프로젝트 요구에 맞게 확장하기 위해 사용되는 패키지 • Profile은 Stereotype과 Tagged Value를 정의하여 표준 SysML 메타모델을 커스터마이징하고, 특정 도메인의 요구사항을 충족하도록 모델링을 조정할 수 있음 • 예를 들어, “항공우주 시스템 프로파일”은 항공우주 도메인에 특화된 Stereotype(예: “FlightCritical”)과 속성을 포함하여, 해당 도메인에 적합한 설계와 분석을 지원할 수 있습니다.
Generalization Path		• Generalization Path는 두 Package 간의 계층적 상속 관계를 표현 • 하위 Package가 상위 Package의 속성, 요소, 구조를 상속받는 것을 의미 • 이 관계는 상위 요소의 공통 기능이나 정의를 하위 요소에서 재사용하거나 확장할 수 있게 합니다. • 다이어그램에서는 빈 삼각형 화살표로 표현되며, 화살표는 상위 Package를 가리킵니다. • 예를 들어, “차량 시스템” Package가 “전기차 시스템” Package와 Generalization Path로 연결되어 있다면, 전기차 시스템이 차량 시스템의 공통 설계 요소를 상속받으면서도 고유의 속성을 추가할 수 있음을 나타냅니다.
Extension Path		• Extension Path는 사용자 정의 Stereotype이 표준 메타클래스를 확장하는 관계를 나타냄 • 이는 프로파일(Profile) 내에서 정의된 Stereotype이 기존 SysML 또는 UML 메타모델의 요소에 새로운 속성이나 제약을 추가할 수 있도록 합니다. • 다이어그램에서는 점선 화살표와 빈 삼각형으로 표현되며, 화살표는 확장되는 표준 메타클래스를 가리킵니다. • 예를 들어, “안전Critical” Stereotype이 Block 메타클래스를 확장하는 Extension Path는 Block 요소에 안전 관련 속성과 규칙을 추가하도록 설정합니다.
Association Path		• Association Path는 두 패키지 간의 관계를 나타내며, 특정 패키지가 다른 패키지와 상호작용하거나 참조되는 방식을 표현합니다. • Association Path는 두 패키지가 서로 연결되어 있음을 나타내며, 이를 통해 패키지 간의 데이터 공유, 의존성, 또는 협업을 시각적으로 명확히 합니다. • 다이어그램에서는 선으로 표현되며, 필요에 따라 방향성을 추가할 수도 있습니다. • 예를 들어, “차량 시스템” 패키지가 “센서 데이터” 패키지와 Association Path로 연결되어 있다면, 차량 시스템이 센서 데이터를 참조하거나 사용하는 관계를 의미합니다.
Reference Path		• Reference Path는 한 패키지가 다른 패키지를 참조하지만 소유하지 않는 관계를 나타냅니다. • 이 관계는 패키지 간의 연결을 표현하면서도 각 패키지의 독립성을 유지하도록 하며, 주로 데이터나 기능을 공유하거나 활용할 때 사용됩니다. • 다이어그램에서는 점선 화살표로 표현되며, 화살표의 시작점이 참조하는 패키지, 끝점이 참조되는 패키지를 가리킵니다. • 예를 들어, “운전자 인터페이스” 패키지가 “UI 컴포넌트” 패키지를 Reference Path로 참조하면, 인터페이스가 UI 컴포넌트를 사용하지만 소유하거나 직접 포함하지 않음을 의미합니다.
Profile Application Path		• Profile Application Path는 특정 Profile이 모델 또는 패키지에 적용되었음을 나타내는 관계를 표현합니다. • Profile Application Path는 모델링 프로젝트에 도메인 특화된 Stereotype과 규칙을 적용하여, 해당 모델을 특정 도메인 요구에 맞게 확장하고 커스터마이징할 수 있게 합니다. • 다이어그램에서는 점선 화살표로 표현되며, 화살표는 모델이나 패키지에서 적용된 Profile을 향합니다. • 예를 들어, “자동차 시스템 모델”이 “안전 프로파일”을 Profile Application Path로 연결하면, 해당 모델이 안전 관련 Stereotype과 속성을 사용할 수 있음을 의미합니다.

 

2. 블록 정의 다이어그램 (SysML::Block Definition Diagram)

Diagram Element	표기법	설명
Block Node		• Block Node는 시스템을 구성하는 주요 구조적 요소를 나타내는 기본 단위입니다. • Block은 물리적, 논리적 구성 요소 모두를 표현할 수 있으며, 속성(Properties), 동작(Operation), 연결(Interface) 등을 포함하여 시스템의 구조적, 기능적 특성을 정의합니다. • 예를 들어, 차량 시스템에서는 “엔진”, “브레이크 시스템” 또는 “센서 모듈”과 같은 주요 구성 요소들이 Block으로 표현될 수 있습니다.
Quantity Kind and Unit Nodes		• Quantity Kind Node와 Unit Node는 시스템 모델에서 물리적 속성을 정량화하고 표준화하기 위한 개념을 나타냅니다. • Quantity Kind는 속성의 물리적 크기(예: 길이, 시간, 질량)를 정의하며, Unit은 해당 Quantity Kind의 측정 단위(예: 미터, 초, 킬로그램)를 지정합니다. • 이 두 요소는 속성 값을 명확히 표현하고, 시스템 설계와 분석 과정에서 일관성을 유지하며, 다양한 단위 체계 간의 변환을 관리하는 데 중요한 역할을 합니다. • 예를 들어, “속도”는 Quantity Kind로 정의되며, “미터/초”와 같은 단위가 연결될 수 있습니다.
Value Type Node		• Value Type Node는 속성의 데이터 유형과 제약 조건을 정의하는 요소로, 시스템 모델에서 값의 표현과 일관성을 유지하는 데 사용됩니다. • Value Type은 물리적 단위(예: 길이, 무게), 논리적 값(예: 상태, 코드), 또는 사용자 정의 데이터 유형을 나타낼 수 있으며, Quantity Kind 및 Unit과 연결되어 측정 단위와 물리적 속성을 정밀하게 표현합니다. • 예를 들어, “Temperature”라는 Value Type은 섭씨(°C) 또는 화씨(°F)의 단위를 갖는 값을 정의할 수 있습니다.
Enumeration Node		• Enumeration Node는 특정 속성이 가질 수 있는 유한한 값들의 집합을 정의하는 데 사용되는 요소입니다. • Enumeration은 주로 상태, 카테고리, 또는 사전 정의된 옵션 집합을 모델링할 때 활용되며, 각 값을 Enumeration Literal로 표현합니다. • 예를 들어, “차량 상태”를 나타내는 Enumeration Node는 “정지”, “주행”, “후진”과 같은 상태 값을 포함할 수 있습니다.
Actor Node		• Actor Node는 시스템 외부에서 시스템과 상호작용하는 주체(사람, 조직, 외부 시스템 등)를 나타내는 요소입니다. • Actor는 시스템의 경계 외부에 위치하며, 시스템의 요구사항 및 동작을 정의하거나 검증하는 데 중요한 역할을 합니다. • 예를 들어, “운전자”, “정비사”, “운송 시스템”과 같은 Actor는 차량 시스템과 상호작용하는 주체로 모델링될 수 있습니다
Interface Block Node		• Interface Block Node는 시스템 내 또는 시스템 간의 상호작용을 정의하는 데 사용되는 요소로, 구조적 연결을 통해 데이터, 신호, 물리적 흐름을 명확히 표현합니다. • Interface Block은 시스템 구성 요소들 간의 통신 규칙을 지정하며, 전달 가능한 속성(Properties)과 동작(Operations)을 정의합니다. • 예를 들어, “센서 인터페이스”는 센서와 제어 유닛 간 데이터를 전달하는 프로토콜과 속성을 포함할 수 있습니다.
Interface Node		• Interface Node는 시스템 구성 요소 간의 상호작용을 정의하며, 데이터, 신호, 서비스 등을 주고받는 명세를 나타냅니다. • Interface는 특정 Block이나 요소가 제공하거나 요구하는 동작(Operations)과 속성(Properties)을 명확히 기술하여, 시스템의 경계를 넘나드는 통신 및 협력을 구조화합니다. • 예를 들어, “통신 인터페이스”는 데이터 전송 규약과 연결 포인트를 정의할 수 있습니다.
Signal Node		• Signal Node는 시스템 내에서 이벤트를 전달하거나 구성 요소 간의 통신을 표현하는 요소로, 주로 비동기 메시지를 모델링하는 데 사용됩니다. • Signal은 데이터나 정보를 포함할 수 있으며, 특정 상황에서 발생하는 이벤트를 수신자에게 알리는 역할을 합니다. • 예를 들어, “충돌 감지 신호”는 차량의 충돌 센서에서 제어 시스템으로 전송되는 경고 이벤트를 모델링할 수 있습니다.
Interface Compartments for Block Node		• Interface Compartment for Block Node는 특정 Block이 제공하거나 요구하는 인터페이스를 명시적으로 나타내는 부분입니다. • 이 컴파트먼트는 Block의 외부와의 상호작용을 정의하며, 제공(Provided) 인터페이스와 요구(Required) 인터페이스를 구분하여 표시합니다. • 예를 들어, “차량 제어 유닛” Block의 Interface Compartment는 “속도 제어” 제공 인터페이스와 “센서 데이터 입력” 요구 인터페이스를 포함할 수 있습니다.
Composite Association Path		• Composite Association Path는 구성 요소 간의 “전체-부분” 관계를 나타내며, 특정 Block이 다른 Block의 구성 요소로 포함되는 것을 의미합니다. • 이 관계는 강한 결합(strong ownership)을 나타내며, 전체(Composite)가 삭제되면 부분(Part)도 함께 삭제됩니다. • 다이어그램에서는 마름모 기호로 표현됩니다. • 예를 들어 “차량” Block과 “엔진” Block 간 Composite Association은 엔진이 차량의 필수 구성 요소임을 나타냅니다.
Reference Association Path		• Reference Association Path는 두 Block 간의 “참조 관계”를 나타내며, 한 Block이 다른 Block을 소유하지 않고 단순히 참조하거나 상호작용하는 관계임을 의미합니다. • 이 관계는 약한 결합(weak ownership)을 나타내며, 참조된 Block의 생명 주기는 참조하는 Block과 독립적입니다. • 다이어그램에서는 일반적인 선으로 표현됩니다. • 예를 들어 “차량” Block이 “GPS 시스템” Block과 Reference Association을 가질 경우, 차량이 GPS 시스템을 참조하지만 이를 소유하거나 관리하지 않음을 나타냅니다.
Associatin Block Path and Node		• Association Block Path와 Node는 두 Block 간의 관계를 명확히 정의하고, 그 관계와 관련된 속성이나 동작을 모델링하는 데 사용됩니다. • Association Block은 단순한 연결을 넘어 관계 자체를 하나의 모델링 요소로 다루며, 관계에 추가적인 속성(Properties)과 동작(Operations)을 부여할 수 있습니다. • 다이어그램에서는 Association Path로 두 Block을 연결하고, 해당 경로 위나 인접한 노드로 Association Block을 표현합니다. • 예를 들어, “차량” Block과 “운전자” Block 간의 관계를 정의하는 Association Block은 “운전자 역할”이나 “책임 수준” 같은 속성을 포함할 수 있습니다.
Generalization Path		• Generalization Path는 Block 간의 계층적 상속 관계를 나타내며, 한 Block(자식)이 다른 Block(부모)의 속성과 동작을 상속받음을 의미합니다. • 이 관계는 다이어그램에서 빈 삼각형 화살표로 표현되며, 화살표는 부모 Block을 가리킵니다. • Generalization은 공통 속성과 동작을 상위 Block에서 정의하고 이를 하위 Block들이 재사용하거나 확장하도록 설계함으로써 모델의 간결성과 일관성을 높입니다. • 예를 들어, “차량” Block이 “승용차”와 “트럭” Block의 부모로 Generalization 관계를 가질 경우, 승용차와 트럭은 차량의 공통 속성과 동작을 상속받게 됩니다.
Full Port Node		• Full Port Node는 시스템 또는 구성 요소가 외부와 상호작용하는 인터페이스를 명확히 표현하는 요소입니다. • Full Port는 Block의 일부로 간주되며, 해당 Port를 통해 데이터, 신호, 물리적 흐름이 주고받아집니다. • Full Port는 Block 자체의 동작과 속성을 직접적으로 나타낼 수 있으며, 특정 역할(Role)을 수행하거나 인터페이스를 제공(Provide)하거나 요구(Require)할 수 있습니다. • 예를 들어, “차량” Block에 “충전 포트” Full Port가 있다면, 이는 차량의 외부 충전 시스템과 연결되는 물리적 또는 논리적 인터페이스를 나타냅니다.
Proxy Port Node		• Proxy Port Node는 시스템이나 구성 요소가 외부와 간접적으로 상호작용하는 지점을 나타내며, 내부 구현 세부사항을 숨기면서 외부 인터페이스를 정의합니다. • Proxy Port는 데이터, 신호, 또는 물리적 흐름이 지나가는 경로를 나타내지만, 자체적으로 동작이나 상태를 가지지 않으며, 내부적으로 다른 Port나 요소에 연결되어 실제 상호작용을 수행합니다.
Proxy Port Node with Interface		• Proxy Port Node with Interface는 외부와의 상호작용을 정의하는 간접적인 인터페이스 지점을 나타내며, 특정 인터페이스를 통해 통신하거나 데이터를 주고받습니다. • Proxy Port는 Block 내부의 세부 구현을 숨기면서, 정의된 인터페이스를 기반으로 외부에서 사용 가능한 기능과 서비스를 명확히 제공합니다. • 예를 들어, “자동차 제어 시스템” Block의 Proxy Port가 “속도 조정 인터페이스”를 가지면, 외부에서 이 Port를 통해 차량 속도를 제어할 수 있지만, 실제 구현은 내부의 세부 시스템에 의해 처리됩니다.
Block Node with Constraint Compartment		• Block Node with Constraint Compartment는 특정 Block에 적용되는 제약 조건을 명시적으로 나타내는 요소입니다. • Constraint Compartment는 시스템의 속성, 동작, 또는 관계에 대해 수학적, 논리적 제약을 정의하며, 시스템 설계 및 분석 과정에서 일관성을 유지하고 규칙을 적용하는 데 사용됩니다. • 예를 들어, “차량” Block의 Constraint Compartment에 maxSpeed ≤ 200 km/h라는 제약 조건이 포함될 수 있습니다.
Constraint Block Node		• Constraint Block Node는 시스템의 특정 속성이나 동작 간의 관계를 수학적 또는 논리적 방식으로 정의하는 요소입니다. • Constraint Block은 매개변수(Parameter)와 제약식을 포함하며, 시스템 설계 및 분석에서 요구사항을 검증하거나 동작을 제어하는 데 사용됩니다. • 예를 들어, “차량 동역학” Constraint Block은 속도 = 거리 / 시간과 같은 관계를 정의하여 속도, 거리, 시간 간의 수학적 연계를 모델링할 수 있습니다.
Instance Specification Node		• Instance Specification Node는 특정 Block의 구체적인 인스턴스를 나타내며, Block의 속성 값과 상태를 특정한 컨텍스트에서 정의합니다. • 이는 시스템의 구체적인 예제나 실제 구현을 모델링하는 데 사용되며, Block이 정의하는 구조나 동작의 특정 시나리오를 나타냅니다. • 예를 들어, “차량” Block의 Instance Specification은 “차량 A”라는 이름의 인스턴스로 나타나며, 이 인스턴스의 속성으로 색상 = 빨강, 속도 = 100km/h 등이 포함될 수 있습니다.
Association Instance Specification (Link) Path		• Association Instance Specification Path는 두 Instance Specification 간의 구체적인 관계를 나타내며, Block에서 정의된 Association을 기반으로 한 특정 시나리오의 실질적인 연결을 모델링합니다. • 이 경로는 시스템의 특정 상태나 시뮬레이션에서 두 인스턴스 간의 상호작용을 명확히 표현하며, 속성 값이나 역할과 같은 구체적인 정보를 포함할 수 있습니다. • 예를 들어, “차량 A”와 “운전자 B”라는 Instance Specification 간의 Association Instance Specification Path는 운전자가 차량을 운전하고 있다는 구체적인 관계를 나타낼 수 있습니다.

 

3. 내부 블록 다이어그램 (SysML::Internal Block Diagram)

Diagram Element	표기법	설명
Part Node		• Part Node는 특정 블록(Block)의 구성 요소(파트)를 나타내는 그래픽 노드입니다. • 이는 블록의 내부 구조를 세부적으로 보여주는 데 사용되며, 블록이 다른 블록들과 어떤 관계를 가지는지, 그리고 구성 요소 간의 상호작용이 어떻게 이루어지는지를 시각적으로 표현합니다. • Part Node는 보통 클래스 다이어그램의 객체(instance)와 유사한 개념으로, 특정 블록의 인스턴스(instance)를 의미하며, 블록이 포함하는 속성(Property)이나 기능(Behavior)의 역할을 나타냅니다.
Actor Part Node		• Actor Part Node는 시스템 외부에서 시스템과 상호작용하는 행위자(Actor)의 역할을 나타냅니다. • 이는 시스템의 내부 구성 요소와 외부 행위자가 주고받는 데이터나 신호, 인터페이스를 명확히 표현하는 데 사용됩니다. • Actor Part Node는 시스템 경계를 넘어 시스템 사용자가 될 수도 있고, 다른 시스템, 환경적 요소 등 시스템 외부와 연관된 엔터티를 나타내며, 내부 블록 다이어그램에서는 이러한 외부 행위자와의 구체적인 연결이나 통신 흐름을 시각화합니다.
Reference Node		• Reference Node는 특정 블록이 직접 소유하지 않고 참조(reference)하는 외부 요소를 나타냅니다. • 이는 블록의 속성(Property) 중 하나로, 해당 블록과 연관된 외부 객체나 다른 블록과의 관계를 시각적으로 표현하는 데 사용됩니다. • Reference Node는 보통 객체 간의 약한 결합(Loose Coupling)을 나타내며, 시스템 구성 요소 간의 독립성과 유연성을 강조합니다.
Participant Property Node		• Participant Property Node는 특정 블록의 구성 요소로 참여하는 속성(Property)을 나타냅니다. • 이는 블록 내부의 구조를 설명하면서, 해당 속성이 다른 블록 또는 시스템과의 상호작용에서 어떤 역할을 하는지 보여줍니다. • Participant Property Node는 블록의 내부 상태나 데이터 흐름에 관여하는 객체나 기능의 일부로, 시스템 동작에서 직접적으로 사용되는 속성을 명확히 식별할 수 있도록 합니다.
Value Property Node		• Value Property Node는 특정 블록의 속성 중 값형 데이터(Value Property)를 나타냅니다. • 이는 블록 내부 구성 요소에서 다루는 정량적 데이터나 속성을 모델링하며, 크기, 질량, 온도, 속도와 같은 물리적 특성이나 기타 계산 가능한 값을 표현하는 데 사용됩니다. • Value Property Node는 시스템 설계에서 매개변수 분석이나 시뮬레이션에 중요한 정보를 제공하며, 블록 간 데이터 교환이나 내부 데이터 흐름을 명확히 시각화하는 데 유용합니다.
Connector Path		• Connector Path는 블록의 구성 요소들 간의 상호작용이나 데이터 흐름, 신호 전달을 시각적으로 나타내는 경로입니다. • 이는 블록 내부의 파트, 속성, 또는 외부 참조 요소 사이의 연결 관계를 정의하며, 물리적 연결(배선, 파이프 등)이나 논리적 연결(데이터 링크, 신호 전달 등)을 표현할 수 있습니다.
Connector Property Path and Node		• Connector Property Path and Node는 블록 간의 연결을 속성(Property)으로 정의하고, 이를 통해 구성 요소 간의 상호작용을 명확히 나타냅니다. • Connector Property Path는 블록의 구조 안에서 연결 자체를 속성으로 모델링하여 연결의 특성(예: 대역폭, 프로토콜, 용량 등)을 정의하거나 제어할 수 있도록 합니다. • Connector Node는 이러한 연결을 시각적으로 표현하며, 블록 또는 구성 요소 간의 데이터 흐름, 신호 전달, 물리적 연결 등을 다이어그램 상에 나타냅니다.
Item Flow Node		• Item Flow Node는 블록 간 또는 구성 요소 간의 특정 데이터, 물리적 객체, 에너지, 또는 기타 항목의 흐름을 나타냅니다. • 이는 Connector 위에 추가 정보를 제공하여, 연결을 통해 전달되는 구체적인 항목이 무엇인지 명시하며, 데이터 패킷, 신호, 자원 등의 이동을 시각적으로 모델링합니다. • Item Flow Node는 시스템 내에서 정보와 자원이 어떻게 이동하고 상호작용하는지를 상세히 표현하여 설계자가 흐름 경로를 이해하고 최적화하도록 돕습니다.

 

4. 파라메트릭 다이어그램 (SysML::Parametric Diagram)

Diagram Element	표기법	설명
Constraint Note		• Constraint Node는 시스템의 특정 매개변수들 간의 관계를 수학적 또는 논리적 제약 조건으로 표현하는 요소입니다. • 이는 시스템 설계 시 요구사항이나 성능 조건을 만족시키기 위해 적용되는 수식을 모델링하며, 변수 간의 종속성, 계산식, 또는 규칙을 나타냅니다. • Constraint Node는 시스템 동작 및 성능 분석, 최적화에 중요한 역할을 하며, 설계자가 시스템의 매개변수 간 관계를 명확히 이해하고 요구사항을 충족시키는지 확인하는 데 유용합니다.
Constraint  Parameter Node		• Constraint Parameter Node는 Constraint Node가 사용하는 입력값과 출력값, 또는 내부 계산에서 참조되는 매개변수를 나타냅니다. • 이는 제약 조건 내에서 변수 간의 계산이나 관계를 정의하는 중요한 요소로, 특정 제약 조건이 작동하기 위해 필요한 값을 입력하거나 결과 값을 출력하는 역할을 합니다. • Constraint Parameter Node는 다른 블록이나 시스템 구성 요소에서 값을 가져오거나 전달받는 인터페이스로 작용합니다.
Constraint Property Node		• Constraint Property Node는 특정 블록의 제약 속성(Constraint Property)을 나타내며, 블록 내부 또는 관련 구성 요소 간의 수학적, 논리적 관계를 정의합니다. • 이는 블록의 속성(Property)으로 선언된 제약을 다이어그램에서 시각화하여, 해당 블록이 제약 조건을 어떻게 포함하고 사용하는지 보여줍니다. • Constraint Property Node는 제약 조건을 블록의 다른 속성이나 매개변수와 연결해 시스템의 동작이나 성능을 분석하고 검증하는 데 도움을 줍니다.
Value Binding Path		• Value Binding Path는 두 매개변수 또는 속성 간의 값이 동일함을 보장하는 연결을 나타냅니다. • 이는 두 요소가 동일한 값을 공유해야 한다는 제약 조건을 명시하며, 일반적으로 Constraint Parameter와 Value Property 또는 다른 매개변수 간의 관계를 표현합니다. • Value Binding Path는 시스템 설계에서 일관성을 유지하고, 특정 값이나 계산 결과가 다른 속성에 정확히 반영되도록 보장하는 데 사용됩니다.

 

5. 활동 다이어그램 (SysML::Activity Diagram)

Diagram Element	표기법	설명
Activity  Parameter Node		• Activity Parameter Node는 활동(Activity)와 외부 환경 간의 데이터, 객체, 신호 등의 입력과 출력을 나타내는 노드입니다. • 이는 활동의 인터페이스 역할을 하며, 활동이 시작될 때 필요한 입력값이나 종료 시 생성되는 출력값을 정의합니다. • Activity Parameter Node는 활동의 경계를 설정하고, 활동 간 데이터 흐름을 명확히 표현하여 설계자가 시스템의 동작과 인터페이스를 이해하고 설계할 수 있도록 지원합니다.
Interruptible Region Node		• Interruptible Region Node는 특정 활동 흐름(액션 또는 그룹화된 액션)이 외부 신호나 조건에 의해 중단될 수 있음을 나타내는 영역입니다. • 이 노드는 활동 내에서 비정상적 상황을 처리하거나 동작을 종료해야 할 필요가 있을 때 사용됩니다. • Interruptible Region은 경계선을 통해 표시되며, 외부 이벤트에 의해 활동 흐름이 중단될 경우 흐름이 해당 영역 밖으로 나가는 Interrupt Flow를 통해 처리됩니다.
Activity Partition Node		• Activity Partition Node는 활동(Action)들이 특정 역할, 책임, 또는 시스템 구성 요소와 연관되어 있음을 나타내는 구획(Partition)을 의미합니다. • 흔히 스윔레인(Swimlane) 형태로 표시되며, 각 파티션은 특정 행위자(Actor), 블록, 서브시스템, 또는 조직 단위에 할당된 동작을 나타냅니다. • Activity Partition Node는 활동 흐름을 논리적으로 그룹화하고, 시스템 내에서 어떤 구성 요소나 주체가 특정 동작을 수행하는지 명확히 시각화하여 역할과 책임을 구분하는 데 유용합니다.
Activity Partition in Action Node		• Activity Partition in Action Node는 특정 Action이 어떤 Activity Partition에 속해 있는지를 나타내며, 해당 동작이 할당된 역할, 책임, 또는 시스템 구성 요소를 구체적으로 표현합니다. • 이는 Action을 수행하는 주체(예: 특정 블록, 행위자, 서브시스템 등)와 동작을 시각적으로 연결하여 시스템 내에서 동작의 책임 소유권을 명확히 합니다. • Activity Partition in Action Node는 설계자가 시스템의 행위 흐름을 구체적으로 이해하고, 구성 요소 간의 협업과 역할 분담을 명확히 분석할 수 있도록 지원합니다.
Structured Activity Node		• Structured Activity Node는 하나의 활동(Activity) 내에서 논리적으로 그룹화된 액션(Action)들을 포함하는 컨테이너 역할을 합니다. • 이 노드는 복잡한 활동을 더 작은 단위로 나누어 구조화하거나 특정 제어 흐름(예: 순차 실행, 반복, 조건부 실행 등)을 모델링할 때 사용됩니다. • Structured Activity Node는 액션 간의 관계를 명확히 정의하고, 활동의 이해와 유지보수를 용이하게 하며, 반복적이거나 조건 기반 동작과 같은 복잡한 제어 흐름을 효과적으로 시각화하는 데 유용합니다.
Merge Node		• Merge Node는 여러 흐름 경로를 단일 경로로 결합하는 데 사용되는 제어 노드입니다. • 이는 활동 내에서 병렬적이지 않은 대안적인 흐름을 하나로 합칠 때 사용되며, 흐름의 선택과 무관하게 단일 경로로 이어지도록 보장합니다. • Merge Node는 조건부 분기(Decision Node)와 자주 함께 사용되며, 흐름이 분기된 후 특정 조건에 따라 다시 하나로 결합되는 시점을 나타냅니다.
Decision Node		• Decision Node는 하나의 흐름을 여러 대안 경로로 분기시키는 제어 노드입니다. 이 노드는 조건에 따라 특정 경로를 선택하도록 모델링하며, 각 경로는 Guard Condition으로 표현되는 조건식에 의해 제어됩니다. • Decision Node는 시스템 동작 내에서 의사결정을 표현하며, 다양한 상황에서 어떤 경로를 선택해야 하는지를 명확히 나타냅니다.
Join Node		• Join Node는 여러 병렬 흐름을 하나의 흐름으로 결합하는 데 사용되는 제어 노드입니다. • 이 노드는 모든 입력 흐름이 완료될 때까지 대기한 후 단일 출력 흐름을 생성하여, 동기화된 작업이 다음 단계로 진행되도록 합니다. • Join Node는 병렬적으로 실행되는 작업을 조정하고, 시스템의 복잡한 동작 흐름을 명확히 표현하는 데 유용합니다.
Fork Node		• Fork Node는 단일 입력 흐름을 여러 병렬 출력 흐름으로 나누는 제어 노드입니다. • 이 노드는 하나의 작업이 시작될 때 동시에 여러 작업이 병렬로 실행되도록 모델링하며, 각 출력 흐름은 독립적으로 진행됩니다. • Fork Node는 병렬 처리나 동시 실행을 표현하는 데 사용되어, 복잡한 시스템의 동작을 효율적으로 시각화하고 설계할 수 있도록 돕습니다.
Initial Node		• Initial Node는 활동(Activity)의 시작점을 나타내는 특수한 제어 노드입니다. • 이는 활동 흐름이 시작되는 지점을 정의하며, 다이어그램에서 하나의 단일 출력 흐름을 통해 첫 번째 동작(Action)으로 연결됩니다. • Initial Node는 활동의 시작을 명확히 표시하여, 설계자가 시스템의 동작 순서를 이해하고 흐름을 구조화할 수 있도록 돕습니다. • 다이어그램에는 반드시 하나의 Initial Node만 포함됩니다.
Activity Final Node		• Activity Final Node는 활동(Activity)의 종료를 나타내는 특수한 제어 노드입니다. • 이 노드에 흐름이 도달하면 활동 전체가 즉시 종료되며, 현재 진행 중인 다른 동작도 모두 중단됩니다. • 이는 활동의 논리적 완료를 정의하며, 다이어그램에서 활동 흐름의 끝을 명확히 표시합니다.
Flow Final Node		• Flow Final Node는 특정 흐름(Flow)을 종료시키는 제어 노드입니다. • 이 노드에 흐름이 도달하면 해당 경로의 동작만 종료되며, 다른 병렬 흐름이나 활동 전체에는 영향을 미치지 않습니다.
Decision Input Behavior Node		• Decision Input Behavior Node는 Decision Node에서 경로 선택을 돕기 위해 실행되는 추가적인 동작 또는 계산을 정의하는 노드입니다. • 이 노드는 입력 데이터를 기반으로 조건을 평가하거나 복잡한 논리를 수행한 후, 어떤 경로를 선택할지 결정하는 데 필요한 결과를 제공합니다. • Decision Input Behavior Node는 단순한 조건 평가 이상의 작업이 필요한 경우 활용됩니다.
Call Action Node		• Call Action Node는 특정 동작(Activity)이나 동작(Action)을 호출하는 노드로, 해당 동작을 실행하거나 재사용하는 역할을 합니다. • 이는 호출 대상의 입력값을 제공하고 출력값을 받을 수 있으며, 호출된 동작이 완료되면 흐름이 계속 진행됩니다. • Call Action은 활동 내에서 모듈화를 지원하며, 복잡한 시스템에서 재사용 가능한 구성 요소를 정의하고 효율적으로 모델링하는 데 유용합니다.
Central Buffer Node		• Central Buffer Node는 활동(Action) 간의 데이터나 객체를 임시로 저장하고 관리하는 저장소 역할을 하는 노드입니다. • 이 노드는 여러 흐름에서 데이터가 동시에 입력되고 출력될 수 있도록 중재하며, 데이터의 순서를 조정하거나 병목현상을 방지하는 데 사용됩니다. •  Central Buffer Node는 데이터가 소비되기 전에 일시적으로 보관되는 중간 지점을 제공하여, 복잡한 데이터 흐름을 명확하고 유연하게 모델링할 수 있도록 돕습니다.
Datastore Node		• Datastore Node는 데이터를 영구적으로 저장하고 관리하는 저장소를 나타내는 노드입니다. • 이는 활동 내에서 데이터를 읽거나 쓰는 작업을 모델링하며, 파일 시스템, 데이터베이스, 또는 기타 지속적인 데이터 저장 매체를 표현하는 데 사용됩니다. • Datastore Node는 데이터를 저장하고 유지할 수 있는 영구성을 제공하므로, 시스템 설계자가 데이터 흐름과 저장소 간의 상호작용을 명확히 모델링할 수 있도록 지원합니다.
Control Operator Action Node		• Control Operator Action Node는 제어 흐름을 기반으로 특정 동작을 실행하거나 계산을 수행하는 노드입니다. • 이 노드는 입력되는 제어 신호(Control Flow)에 따라 로직을 처리하거나 시스템 상태를 변경하는 역할을 하며, 복잡한 제어 논리를 모델링하는 데 사용됩니다. • Control Operator Action은 시스템의 동작 흐름을 유연하게 조정하고, 다양한 조건 및 제어 흐름 시나리오를 다룰 수 있도록 도와줍니다.
Accept Event Action Node		• Accept Event Action Node는 특정 이벤트(Event)가 발생하거나 신호(Signal)가 도착할 때까지 대기하는 동작을 나타냅니다. • 이 노드는 입력 이벤트를 수신하면 실행 흐름을 활성화하며, 시스템의 이벤트 기반 동작을 모델링하는 데 사용됩니다. • Accept Event Action Node는 이벤트 발생 시점과 이벤트에 반응하는 동작을 명확히 표현하여, 설계자가 이벤트 중심의 시스템 동작을 이해하고 시뮬레이션할 수 있도록 지원합니다.
Accept Time Event Node		• Accept Time Event Node는 특정 시간 조건(예: 일정 시간 경과, 특정 시점 도달 등)이 만족될 때까지 대기하는 동작을 나타냅니다. • 이 노드는 시간 기반 이벤트를 수신하며, 지정된 시간이 지나거나 조건이 충족되면 실행 흐름을 활성화합니다. • Accept Time Event Node는 시간 중심의 시스템 동작을 모델링하는 데 유용하며, 설계자가 시스템의 시간 제약 및 시간 관련 이벤트를 명확히 표현할 수 있도록 지원합니다.
Send Signal Action		• Send Signal Action은 특정 신호(Signal)를 다른 활동이나 객체로 전송하는 동작을 나타냅니다. • 이 노드는 시스템 내의 구성 요소 간에 데이터나 이벤트를 전달하는 데 사용되며, 신호를 보내는 주체와 신호를 받는 대상 간의 상호작용을 모델링합니다. • Send Signal Action은 비동기적으로 작동하며, 신호가 전송된 후에는 송신자가 다음 작업으로 즉시 진행할 수 있습니다.
Primitive Action Node		• Primitive Action Node는 시스템에서 수행되는 기본적이고 미리 정의된 동작을 나타내는 노드입니다. • 이는 복잡한 동작이 아닌, 시스템 설계와 실행에서 자주 사용되는 간단한 작업(예: 객체 생성, 속성 설정, 신호 전송 등)을 모델링합니다. • Primitive Action Node는 시스템의 기본적인 동작을 명확히 시각화하고, 복잡한 동작의 구성 요소로 활용될 수 있습니다.
Object Flow Path		• Object Flow Path는 활동 간에 데이터나 객체가 이동하는 경로를 나타냅니다. • 이 경로는 특정 액션(Action)에서 생성된 데이터나 객체가 다른 액션으로 전달되어 사용되는 과정을 시각적으로 표현합니다. • Object Flow Path는 활동 간의 데이터 흐름을 명확히 보여주어, 시스템의 동작이 어떻게 상호작용하며 데이터를 처리하는지 이해할 수 있도록 돕습니다.
Control Flow Path		• Control Flow Node는 활동(Action) 간의 실행 순서를 정의하는 경로를 나타냅니다. • 이는 액션이 끝난 후 다음 액션으로 제어 흐름을 전달하여, 활동의 실행 순서를 제어합니다. • Control Flow는 데이터나 객체를 전달하지 않으며, 순전히 실행 흐름을 관리하는 데 사용됩니다.
Object Flow Node		• Object Flow Node는 액션(Action) 간에 데이터나 객체를 전달하는 흐름을 나타냅니다. • 이 노드는 특정 액션에서 생성되거나 수정된 객체가 다른 액션에서 사용되도록 하여, 시스템 내 데이터의 이동 및 처리를 시각적으로 표현합니다. • Object Flow Node는 데이터 흐름을 명확히 보여주어 설계자가 시스템의 입력, 출력, 및 중간 데이터를 효율적으로 관리하고, 구성 요소 간 상호작용을 분석할 수 있도록 지원합니다.
Interrupting Edge Path		• Interrupting Edge Path는 Interruptible Region에서 외부 이벤트나 조건에 의해 활동 흐름을 중단시키는 경로를 나타냅니다. • 이 경로는 특정 이벤트가 발생했을 때 지정된 영역 내의 동작을 종료하고 새로운 흐름으로 전환하도록 모델링됩니다. • Interrupting Edge Path는 시스템에서 예외 상황이나 외부 신호에 반응해야 하는 시나리오를 시각적으로 표현하며, 비정상적 동작이나 중단 로직을 명확히 정의하는 데 사용됩니다.

 

6. 시퀀스 다이어그램 (SysML::Sequence Diagram)

Diagram Element	표기법	설명
Lifeline Node		• Lifeline Node는 특정 객체, 구성 요소, 또는 시스템의 행위자를 나타내며, 시간 축을 따라 해당 엔티티가 메시지 교환에 어떻게 참여하는지를 시각적으로 표현합니다. • Lifeline은 다이어그램의 상단에 해당 엔티티를 식별하는 이름과 함께 시작되며, 수직선으로 시간 흐름을 표시합니다. • 이 노드는 메시지, 신호, 호출 등의 상호작용을 명확히 나타내어 시스템 구성 요소 간의 동작 흐름을 추적하고 분석하는 데 중요한 역할을 합니다.
Single- compartment Fragment Node		• Single-Compartment Fragment Node는 특정 조건이나 제어 구조에 따라 시퀀스를 그룹화하거나 분기, 반복, 예외 처리를 표현하는 데 사용되는 요소입니다. • 이 노드는 다이어그램의 특정 부분을 사각형으로 감싸고, 상단에 제어 연산자(예: alt for alternative, loop for iteration, opt for optional 등)와 조건을 표시합니다. • 단일 구획(Single Compartment)으로 구성되어 제어 흐름 또는 시나리오를 단순하게 정의하며, 복잡한 상호작용을 간결하게 표현할 수 있도록 돕습니다.
Multi- compartment Fragment Node		• Multi-Compartment Fragment Node는 시퀀스를 조건이나 제어 구조에 따라 그룹화하며, 여러 실행 경로(Compartment)를 시각적으로 구분하여 표현하는 요소입니다. • 이 노드는 상단에 제어 연산자(예: alt for alternative, par for parallel, critical for critical section 등)와 함께 각 구획에 별도의 조건이나 시나리오를 정의합니다. • 다중 구획(Multi-Compartment)을 통해 복잡한 상호작용이나 분기 흐름을 명확히 나타내며, 시스템의 다양한 실행 경로를 직관적으로 표현할 수 있습니다.
Filtering Fragment Node		• Filtering Fragment Node는 다이어그램에서 특정 조건이나 기준에 따라 메시지 또는 상호작용을 필터링하여 표시하는 데 사용되는 요소입니다. • 이 노드는 다이어그램의 시각적 복잡성을 줄이고, 관심 있는 특정 메시지나 상호작용만을 강조함으로써 분석과 설계를 용이하게 합니다. • Filtering Fragment는 특정 조건(예: 메시지 유형, 송신자, 수신자 등)을 정의하며, 해당 조건을 만족하는 메시지와 상호작용만을 포함하도록 제한합니다.
State Invariant  Symbol		• State Invariant Symbol은 특정 시점에서 Lifeline의 객체가 만족해야 하는 상태 조건을 나타내는 요소입니다. • 이 심볼은 Lifeline 위에 배치되어 객체가 해당 상태나 조건을 충족하고 있음을 명시하며, 일반적으로 상태의 불변 조건이나 특정 상태를 유지해야 하는 요구사항을 모델링합니다. • State Invariant Symbol은 시스템의 상태 기반 동작을 명확히 시각화하고, 상태 변화가 중요한 설계에서 요구사항 준수를 검증하는 데 유용합니다.
Interaction Use Node		• Interaction Use Node는 다른 시퀀스 다이어그램이나 상호작용(interaction)을 참조하고 재사용할 수 있도록 하는 요소입니다. • 이 노드는 사각형으로 표시되며, 참조하는 상호작용의 이름과 필요한 매개변수를 포함합니다. • Interaction Use는 반복적으로 사용되는 상호작용을 간결하게 표현하여 다이어그램의 복잡성을 줄이고, 설계를 더 체계적이고 모듈화되게 만드는 데 유용합니다.
Synchronous Message		• Synchronous Message는 호출된 동작이 완료될 때까지 호출자가 대기하는 메시지를 나타냅니다. • 이는 일반적으로 요청-응답 패턴을 표현하며, 호출된 엔티티가 작업을 수행한 후 제어를 호출자에게 반환합니다. • Synchronous Message는 실선 화살표로 표현되고, 작업 완료 후 반환되는 응답은 점선 화살표로 표시됩니다. • 이 메시지는 호출과 응답 간의 명확한 흐름을 모델링하여, 시스템 내에서 동기적으로 작동하는 구성 요소 간의 상호작용을 표현하는 데 사용됩니다.
Asynchronous Message		• Asynchronous Message는 호출자가 메시지를 보내고 즉시 다음 작업으로 진행하며, 호출된 동작의 완료 여부를 기다리지 않는 메시지를 나타냅니다. • 이는 비동기적 상호작용을 표현하며, 일반적으로 이벤트 기반 시스템이나 병렬 프로세스를 모델링할 때 사용됩니다. • Asynchronous Message는 끝이 열려 있는 화살표로 표시되며, 호출된 엔티티는 작업을 완료한 후 호출자에게 제어를 반환하지 않아도 됩니다.
Reply Message		• Reply Message는 호출된 동작이 완료된 후 호출자에게 결과를 반환하는 메시지를 나타냅니다. • 이는 Synchronous Message와 함께 사용되며, 호출된 엔티티가 작업을 수행한 결과를 호출자에게 전달하거나 단순히 제어를 반환할 때 모델링됩니다. • Reply Message는 점선 화살표로 표현되며, 반환 값이 포함될 수 있습니다. •  이 메시지는 요청-응답 패턴의 일부로, 시스템의 동기적 상호작용을 상세히 표현하고 설계자가 결과 전달 및 제어 흐름을 명확히 이해할 수 있도록 돕습니다.
Lost Message Path		• Lost Message Path는 메시지가 전송되었지만 수신자가 정의되지 않거나 명확하지 않은 경우를 나타냅니다. • 이는 시스템 내에서 메시지가 의도된 대상에 도달하지 못하거나 분실된 상황을 모델링하며, 주로 시스템 설계의 오류나 예외 처리를 표현하는 데 사용됩니다. • Lost Message는 끝이 채워진 화살표로 표시되며, 화살표의 종단은 수신자가 없는 상태를 나타냅니다.
Found Message Path		• Found Message Path는 수신자는 명확히 정의되어 있지만, 메시지의 송신자가 다이어그램 내에 나타나지 않은 경우를 나타냅니다. • 이는 시스템 외부에서 발생한 이벤트나 예상치 못한 입력, 또는 다이어그램 경계 외부에서 발생한 상호작용을 모델링하는 데 사용됩니다. • Found Message는 화살표의 시작점이 비어 있는 상태로 표시되며, 수신자는 명확히 나타납니다.
Activation Node		• Activation Node는 Lifeline 상에서 객체가 특정 동작을 실행 중임을 나타내는 시각적 표시입니다. • 이는 직사각형 형태로 Lifeline 위에 그려지며, 해당 객체가 메시지를 수신하거나 다른 동작을 호출하여 활성 상태에 있는 기간을 나타냅니다. • Activation Node는 호출된 작업의 시작부터 종료까지를 나타내며, 시스템 내 동작 실행의 순서를 명확히 시각화하는 데 사용됩니다.
Create Message Path		• Create Message Path는 특정 객체나 인스턴스가 실행 중에 생성되는 과정을 나타내는 메시지 경로입니다. • 이는 객체가 Lifeline 상에서 처음 등장하는 시점을 모델링하며, 객체 생성 요청을 보내는 호출자와 생성된 객체 간의 상호작용을 표현합니다. • Create Message Path는 객체의 Lifeline 시작점에서 연결된 실선 화살표로 표시됩니다.
Destory Event Node		• Destroy Event Node는 특정 객체나 인스턴스가 소멸되는 시점을 나타내는 요소입니다. • 이 노드는 객체의 Lifeline 끝에 위치하며, 일반적으로 X로 표시됩니다. • Destroy Event는 객체가 더 이상 활성 상태가 아니거나 시스템에서 제거된다는 것을 의미하며, 메시지를 통해 소멸 동작이 트리거되는 경우를 표현할 수도 있습니다.
Coregion Symbol		• Coregion Symbol은 두 개 이상의 메시지가 순서에 관계없이 병렬로 처리될 수 있음을 나타내는 기호입니다. • 이 심볼은 Lifeline의 수직선에서 중괄호 {}로 표시되며, 해당 영역 안의 메시지들은 동등한 우선순위를 가지고 비순차적으로 발생할 수 있음을 의미합니다. • Coregion Symbol은 시스템에서 동시성이나 병렬 처리를 시각적으로 표현하는 데 유용하며, 설계자가 병렬 동작 시나리오를 명확히 모델링하고 분석할 수 있도록 돕습니다.
Duration Observation Symbol		• Duration Observation Symbol은 두 지점 간의 시간 지속 기간을 측정하고 표현하는 데 사용되는 기호입니다. • 이 심볼은 두 이벤트 사이에 위치하며, 지속 시간 값이 함께 표시됩니다. • 이는 시스템 동작 중 특정 작업이나 상호작용이 얼마나 오래 걸리는지를 시각화하여 시간 제약이나 성능 분석에 유용합니다. • Duration Observation Symbol은 시스템의 타이밍 요구사항을 명확히 하고, 시간 기반 동작의 적합성을 검증하거나 최적화하는 데 중요한 정보를 제공합니다.
Duration Constraint Symbol		• Duration Constraint Symbol은 두 이벤트 간 지속 시간이 특정 제한 조건을 만족해야 함을 나타내는 기호입니다. • 이 심볼은 지속 시간을 표현하는 선 위에 제한 조건(예: 1s < t < 5s)으로 표시되며, 시스템 동작이 정의된 시간 제약 내에서 실행되어야 함을 모델링합니다. • Duration Constraint Symbol은 타이밍 요구사항을 명확히 시각화하고, 시스템이 시간 기반 성능 요구를 충족하는지 검증하는 데 유용합니다.
Time Observation Symbol		• Time Observation Symbol은 특정 이벤트가 발생한 정확한 시간을 기록하거나 참조하는 데 사용되는 기호입니다. • 이 심볼은 이벤트 옆에 시간 식별자(예: t1)와 함께 표시되며, 시스템 동작의 특정 시점에 대해 시간 데이터를 명확히 정의합니다. • Time Observation Symbol은 타이밍 분석이나 시간 기반 요구사항을 검증하는 데 유용하며, 시스템의 동작이 특정 시간 조건에 부합하는지 확인할 수 있도록 돕습니다.
Time Constraint Symbol		• Time Constraint Symbol은 특정 이벤트가 발생해야 하는 시간 조건이나 제약을 정의하는 기호입니다. • 이 심볼은 Lifeline의 특정 지점이나 이벤트에 부착되며, 시간 조건(예: t < 5s)을 표시하여 해당 이벤트가 제약된 시간 내에 발생해야 함을 명시합니다. • Time Constraint Symbol은 시스템의 시간 기반 요구사항을 시각적으로 표현하고, 타이밍 제약을 충족하는지 검증하는 데 유용합니다.

 

7. 상태 기계 다이어그램 (SysML::State Machine Diagram)

Diagram Element	표기법	설명
State Machine with Entry- and Exit-Point Pseudostate Nodes		• Entry-and Exit-Point Pseudostate Nodes는 상태(State)와 상태 기계(State Machine)의 진입과 종료 지점을 정의하는 특수 노드입니다. • Entry Point는 상태나 상태 기계가 외부에서 진입할 때 시작되는 지점을 나타내며, 특정 진입 동작이나 초기화를 실행할 수 있습니다. • Exit Point는 상태나 상태 기계가 외부로 전환되거나 종료될 때의 지점을 나타내며, 이를 통해 종료 동작을 정의할 수 있습니다. • 이러한 노드는 상태 기계 내부의 복잡한 전환 흐름을 캡슐화하거나 간소화하여, 상태 간의 명확한 진입 및 종료 경로를 모델링하는 데 사용됩니다.
Atomic State Node		• Atomic State Node는 더 이상 세분화되지 않는 가장 기본적인 단위를 나타내는 상태입니다. • 이 상태는 내부에 하위 상태나 상태 기계가 없는 단순 상태로, 특정 조건이 충족되면 바로 전환(Transition)을 통해 다른 상태로 이동합니다. • Atomic State는 시스템의 단일 동작이나 조건을 모델링하며, 간단한 상태 기반 로직을 표현할 때 사용됩니다.
Composite State with Entry- and Exit-Point Pseudostate Nodes		• Composite State with Entry- and Exit-Point Pseudostate Nodes는 내부에 하위 상태나 상태 기계를 포함한 복합 상태(Composite State)로, 진입점(Entry Point)과 종료점(Exit Point)을 통해 상태 전환이 이루어지는 구조를 나타냅니다. • Entry Point는 외부에서 복합 상태로 진입할 때 시작되는 지점을 정의하고, Exit Point는 복합 상태를 벗어날 때 경로를 지정하여 상태 전환을 제어합니다. • 이러한 노드는 복잡한 상태 간 전환 로직을 캡슐화하거나 간소화하며, 시스템의 구조적 명확성과 재사용성을 높이는 데 사용됩니다.
Composite State Node with Multiple Regions		• Composite State Node with Multiple Regions는 내부적으로 병렬적으로 실행되는 여러 독립적인 상태 영역(Regions)을 포함하는 복합 상태를 나타냅니다. • 각 영역은 자체 상태와 전환(Transitions)을 가지고 있으며, 병렬로 동시에 동작할 수 있는 구조를 제공합니다. • 이러한 노드는 시스템 내에서 독립적이지만 동시에 발생하는 동작을 모델링하는 데 사용되며, 병렬성을 명확히 표현하여 복잡한 상태 기계를 단순화할 수 있습니다.
Sub-State Machine Node with Connection  Points		• Sub-State Machine Node with Connection Points는 상위 상태(State)가 하위 상태 기계(Sub-State Machine)를 포함하며, 진입(Entry Point) 및 종료(Exit Point) 지점을 통해 상위 상태와 연결되는 구조를 나타냅니다. • 이 노드는 복잡한 상태 전환을 캡슐화하여 하위 상태 기계로 위임하고, 상위 상태 기계와의 인터페이스를 간소화합니다. • Connection Points는 하위 상태 기계 내부의 상태 흐름과 외부 상태 간의 전환을 정의하여, 하위 상태 기계가 특정 조건을 만족하면 외부 전환을 시작하거나 종료할 수 있도록 합니다.
Terminate Pseudostate Node		• Terminate Pseudostate Node는 상태 기계의 실행이 완전히 종료되는 시점을 나타내는 특수한 상태 노드입니다. • 이 노드에 도달하면 모든 활동이 즉시 중단되며, 상태 기계의 동작은 더 이상 진행되지 않습니다. Terminate Pseudostate는 시스템이나 구성 요소의 수명 주기를 끝내거나 예외적인 종료를 모델링하는 데 사용됩니다.
Initial Pseudostate Node		• Initial Pseudostate Node는 상태 기계나 특정 상태의 시작 지점을 나타내는 특수한 상태 노드입니다. • 이는 상태 기계 실행 시 처음 활성화되는 지점으로, Initial Pseudostate에서 시작하여 첫 번째 상태로의 전환(Transition)이 이루어집니다. • 이 노드는 다이어그램에 반드시 하나만 존재하며, 상태 기계의 초기 동작을 명확히 정의하는 데 사용됩니다.
Final State Node		• Final State Node는 상태 기계 또는 특정 상태의 실행이 완료되었음을 나타내는 종료 지점입니다. • 이 노드는 상태 기계의 흐름이 끝나는 위치를 정의하며, 해당 상태에 도달하면 모든 활동과 전환이 종료됩니다. • Final State는 원 모양으로 표시되며, 시스템이나 서브시스템의 정상적인 종료를 모델링하는 데 사용됩니다.
Choice Pseudostate Node		• Choice Pseudostate Node는 여러 가능한 경로 중 하나를 선택하여 전환(Transition)하도록 하는 분기 지점입니다. • 이 노드는 하나의 입력 전환과 여러 개의 출력 전환을 가지며, 각 출력 전환은 조건식(Guard)을 기반으로 선택됩니다. • Choice Pseudostate는 상태 전환이 실행 중에 동적으로 평가되는 조건에 따라 결정되어야 하는 경우에 사용됩니다.
Junction Pseudostate Node		• Junction Pseudostate Node는 여러 전환(Transition)을 결합하거나 분리하여 상태 흐름을 단순화하는 연결 지점입니다. • 이 노드는 여러 입력 전환과 여러 출력 전환을 가질 수 있으며, 출력 전환은 조건식(Guard)에 따라 선택됩니다. • Junction Pseudostate는 상태 흐름에서 복잡한 조건 로직을 모델링하거나, 공통 경로를 정의하여 중복을 줄이는 데 유용합니다.
Trigger Node		• Trigger Node는 특정 이벤트(Event)가 발생했을 때 상태 전환(Transition)을 시작하는 조건을 정의하는 요소입니다. • 트리거는 상태 전환의 시작을 유발하며, 일반적으로 신호(Signal), 호출(Call), 시간(Time), 변경(Change) 등 다양한 이벤트 유형으로 표현됩니다. • Trigger Node는 상태 기계가 외부 입력이나 시스템 내부 이벤트에 반응하는 방식을 모델링하며, 상태 전환의 원인을 명확히 나타냅니다.
Action  Node		• Action Node는 상태 전환(Transition) 중 또는 특정 상태(State) 내에서 수행되는 동작을 나타냅니다. • Entry Actions, Exit Actions, 또는 Do Actions와 같은 유형으로 분류되며, 상태에 진입하거나 종료할 때, 또는 상태가 활성화된 동안 실행됩니다. • Action Node는 간단한 계산, 메시지 전송, 데이터 업데이트 등 시스템의 동작을 모델링하며, 상태와 상태 전환의 동작을 구체적으로 정의하는 데 사용됩니다.
Send Signal Node		• Send Signal Node는 특정 신호(Signal)를 외부 시스템, 객체, 또는 내부 상태 기계의 다른 구성 요소로 전송하는 동작을 나타냅니다. • 이는 상태 전환 중 또는 상태 내에서 실행될 수 있으며, 신호는 이벤트 트리거로 작동하여 다른 상태 기계나 구성 요소의 동작을 활성화할 수 있습니다. • Send Signal Node는 시스템 간 상호작용을 모델링하는 데 사용되며, 시스템의 이벤트 기반 동작을 시각적으로 명확히 표현합니다.
Join Pseudostate Node		• Join Pseudostate Node는 병렬로 실행되던 여러 상태 흐름을 하나로 합치는 지점을 나타냅니다. • 이 노드는 모든 입력 흐름이 완료될 때까지 대기한 후 단일 출력 흐름으로 전환을 진행합니다. Join Pseudostate는 동기화를 표현하며, 병렬 실행 상태 간의 조정을 모델링하는 데 사용됩니다.
Fork Pseudostate Node		• Fork Pseudostate Node는 단일 입력 흐름을 여러 병렬 흐름으로 나누는 지점을 나타냅니다. • 이는 시스템에서 동시 실행이 필요한 병렬 상태들을 활성화하기 위해 사용됩니다. • Fork Pseudostate는 하나의 입력 전환(Transition)에서 시작하여 여러 개의 출력 전환으로 분기하며, 각 병렬 흐름은 독립적으로 실행됩니다.
History Pseudostate Node		• History Pseudostate Node는 복합 상태(Composite State)에서 마지막으로 활성화된 하위 상태(Substate)를 기억하여, 복합 상태로 재진입할 때 이전 상태로 복원할 수 있도록 하는 노드입니다. • 두 가지 유형이 있으며, Shallow History는 바로 한 단계의 하위 상태를 기억하고, Deep History는 계층적으로 포함된 모든 하위 상태까지 기억합니다. • History Pseudostate는 상태 복구나 반복적인 상태 전환이 필요한 시나리오를 모델링하는 데 유용하며, 시스템의 상태 복원 동작을 간결하고 효율적으로 표현할 수 있습니다.
Time Event Transition Path		• Time Event Transition Path는 특정 시간 조건이 충족되었을 때 상태 전환(Transition)을 유발하는 경로를 나타냅니다. • 이 경로는 일정 시간 경과(예: after(5s)) 또는 특정 시간에 도달(예: at(12:00PM))과 같은 시간 기반 이벤트를 트리거로 사용합니다. • Time Event Transition Path는 시간 제약이 중요한 시스템 동작을 모델링하며, 상태 전환이 정확한 타이밍 요구사항을 충족하는지 분석할 수 있도록 합니다.
Signal Event Transiton Path		• Signal Event Transition Path는 특정 신호(Signal)가 수신될 때 상태 전환(Transition)을 유발하는 경로를 나타냅니다. • 이 경로는 시스템 내부 또는 외부로부터 발생하는 신호를 트리거로 사용하며, 신호의 수신은 명확히 정의된 전환 조건으로 동작합니다. • Signal Event Transition Path는 이벤트 기반 시스템이나 구성 요소 간 상호작용을 모델링하는 데 사용되며, 시스템의 반응적 동작을 시각적으로 표현합니다.
Call Event Transition Path		• Call Event Transition Path는 특정 호출 이벤트(Call Event)가 발생했을 때 상태 전환(Transition)을 유발하는 경로를 나타냅니다. • 호출 이벤트는 일반적으로 메서드 호출이나 특정 동작 실행 요청으로 정의되며, 상태 기계가 이를 수신하면 전환이 트리거됩니다. • 이 경로는 동작 호출과 응답을 모델링하는 데 사용되며, 시스템의 동작 흐름이나 상호작용을 명확히 표현합니다. • Call Event Transition Path는 호출 기반의 트리거 조건을 시각화하고, 시스템 구성 요소 간의 동작 연계를 체계적으로 설계하는 데 유용합니다.
Change Event Transition Path		• Change Event Transition Path는 특정 조건식이 참으로 평가될 때 상태 전환(Transition)을 유발하는 경로를 나타냅니다. • 이 경로는 시스템의 속성이나 변수 값의 변화에 따라 상태 전환이 발생하도록 정의됩니다. • 조건식은 when(x > 10)과 같은 형식으로 표현되며, 지속적으로 평가되어 조건이 만족되면 즉시 전환이 실행됩니다. • Change Event Transition Path는 값이나 상태의 변화에 민감한 시스템 동작을 모델링하는 데 사용되며, 설계자가 조건 기반 상태 전환을 명확히 정의하고 시스템 동작을 효과적으로 제어할 수 있도록 합니다.

 

8. 유즈케이스 다이어그램 (SysML::Use Case Diagram)

Diagram Element	표기법	설명
Actor Node		• Actor Node는 시스템과 상호작용하는 외부 엔티티를 나타냅니다. • Actor는 시스템의 사용자(사람)일 수도 있고, 다른 시스템, 하드웨어, 소프트웨어 등 시스템 외부에서 시스템과 데이터를 교환하거나 동작을 유발하는 모든 요소를 포함합니다. • Actor Node는 일반적으로 스틱맨(Stickman) 기호로 표현되며, 특정 유스케이스와 연결되어 해당 상호작용의 주체를 명확히 나타냅니다.
Use Case Node		• Use Case Node는 시스템이 특정 Actor 또는 다른 시스템과의 상호작용에서 제공해야 하는 기능이나 서비스를 나타냅니다. • 이는 시스템이 수행해야 할 동작이나 시나리오를 모델링하며, 타원형으로 표현됩니다. • 각 유스케이스는 특정 목표를 달성하기 위한 일련의 동작 또는 절차를 정의하며, Actor와의 관계(Association)를 통해 해당 유스케이스를 사용하는 주체를 명시합니다.
Subject Node		• Subject Node는 특정 유스케이스와 관련된 시스템, 서브시스템, 구성 요소 또는 맥락을 나타내는 요소입니다. • 보통 사각형으로 표현되며, 그 내부에 해당 시스템 또는 서브시스템이 지원하거나 제공하는 유스케이스를 포함합니다. • Subject Node는 다이어그램의 경계를 정의하고, 유스케이스와 상호작용하는 Actor 및 외부 요소 간의 관계를 명확히 구분하는 역할을 합니다
Association Path		• Association Path는 Actor와 Use Case 간의 관계를 나타내는 선으로, 특정 Actor가 해당 유스케이스를 사용하는 주체임을 시각적으로 표현합니다. • 이 경로는 Actor와 유스케이스 간의 상호작용 또는 데이터 흐름을 명확히 정의하며, 다이어그램에서 시스템의 사용자와 기능 간의 연결을 이해하는 데 도움을 줍니다.
Extension Path		• Extension Path는 기존 유스케이스를 확장하여 조건부 또는 선택적으로 추가 동작을 수행하는 유스케이스 간의 관계를 나타냅니다. • 이 경로는 «extend» 라벨과 함께 점선 화살표로 표시되며, 화살표의 방향은 확장되는 기본 유스케이스를 가리킵니다. • Extension Path는 특정 조건이 만족될 때 추가적인 동작이나 시나리오를 실행하도록 설계되었으며, 유스케이스의 기능적 유연성과 재사용성을 높이는 데 사용됩니다.
Inclusion Path		• Inclusion Path는 하나의 유스케이스가 공통 동작이나 하위 기능을 다른 유스케이스로 분리하여 포함하는 관계를 나타냅니다. • 이 경로는 «include» 라벨과 함께 점선 화살표로 표시되며, 화살표는 포함되는(Target) 유스케이스를 가리킵니다. • Inclusion Path는 반복적으로 사용되는 동작을 재사용하거나, 복잡한 유스케이스를 더 작은 단위로 나누어 설계할 때 유용합니다.
Generalization Path		• Generalization Path는 유스케이스나 Actor 간의 일반화-특수화 관계를 나타냅니다. • 이 경로는 부모(일반적인) 요소에서 자식(특수한) 요소로 이어지는 실선 화살표로 표시되며, 화살표 머리가 부모 요소를 가리킵니다. • Generalization은 자식 요소가 부모 요소의 속성과 동작을 상속받으면서도 자신만의 추가적인 특성을 가질 수 있음을 의미합니다.

 

9. 요구사항 다이어그램 (SysML::Requirement Diagram)

Diagram Element	표기법	설명
Requirement Node		• Requirement Node는 시스템이 충족해야 할 특정 조건, 제약, 또는 목표를 나타내는 요소입니다. • 이 노드는 사각형으로 표현되며, 내부에 요구사항의 고유 식별자(ID)와 텍스트로 요구사항 내용을 기술합니다. • Requirement Node는 시스템 설계의 기준점으로, 다른 다이어그램 요소와의 관계를 통해 추적 가능성(Traceability)을 지원합니다.
Requirement Related-Type Node		• Requirement Related-Type Node는 요구사항과 다른 모델 요소(예: 설계, 테스트, 컴포넌트 등) 간의 관계를 나타내는 노드입니다. • 이 노드는 요구사항 자체가 아닌, 요구사항을 구현하거나 검증, 추적하는 데 관여하는 관련 정보를 시각화하는 역할을 합니다. • 보통 추적 가능성(Traceability)을 지원하는 다양한 관계(예: 만족(Satisfy), 검증(Verify), 파생(Derive))를 표현하며, 요구사항과 시스템 모델 간의 연관성을 체계적으로 나타냅니다.
Trace Compartment		• Trace Compartment는 요구사항 노드의 하단 부분에 위치하며, 해당 요구사항과 연관된 추적 가능성(Traceability) 정보를 제공하는 공간입니다. • 이 컴파트먼트에는 요구사항과 다른 모델 요소 간의 관계(예: 다른 요구사항, 설계 요소, 테스트 케이스 등)가 나열됩니다. • Trace Compartment는 요구사항이 시스템 설계나 검증 과정에서 어떻게 참조되고 활용되는지 명확히 보여줍니다.
Package Node		• Package Node는 요구사항과 관련된 요소들을 그룹화하여 체계적으로 관리하기 위한 컨테이너 역할을 합니다. • 이 노드는 사각형 상단에 패키지 이름이 표시되며, 내부에 요구사항, 모델 요소, 또는 다른 패키지를 포함할 수 있습니다. • Package Node는 요구사항의 논리적 구조를 정의하고, 대규모 시스템에서 요구사항을 분류하거나 계층적으로 정리하는 데 유용합니다.
Test Case Node		• Test Case Node는 특정 요구사항을 검증하기 위해 수행되는 테스트 절차나 시나리오를 나타내는 요소입니다. • 이 노드는 요구사항과의 관계(예: «verify»)를 통해, 해당 테스트 케이스가 어떤 요구사항을 검증하는지를 명확히 표시합니다. • Test Case Node는 요구사항의 충족 여부를 확인하고, 시스템의 품질과 일관성을 보장하기 위한 핵심 요소로 사용됩니다.
Containment Path		• Containment Path는 요구사항 간의 포함(Containment) 관계를 나타내는 경로입니다. • 이 경로는 하나의 요구사항이 다른 요구사항의 일부임을 나타내며, 부모-자식 관계로 구조화된 요구사항 계층을 표현합니다. • Containment Path는 요구사항의 세분화 또는 구성 요소화를 시각화하여 복잡한 요구사항을 체계적으로 관리하는 데 유용합니다.
Derivation Path		• Derivation Path는 하나의 요구사항이 다른 요구사항으로부터 도출되었음을 나타내는 관계 경로입니다. • 이 경로는 점선 화살표로 표시되며, 화살표의 방향은 도출된 요구사항(Derived Requirement)을 가리킵니다. • Derivation Path는 시스템 설계에서 고수준의 추상적인 요구사항이 세부적인 하위 요구사항으로 구체화되는 과정을 시각적으로 표현합니다.
Satisfaction Path		• Satisfaction Path는 특정 모델 요소(예: 설계, 구성 요소, 시스템)가 특정 요구사항을 충족함(Satisfy)하는 관계를 나타내는 경로입니다. • 이 경로는 «satisfy» 라벨과 함께 점선 화살표로 표시되며, 화살표는 충족되는 요구사항을 가리킵니다. • Satisfaction Path는 설계 요소가 요구사항을 어떻게 구현하거나 달성하는지를 시각적으로 표현하며, 요구사항과 시스템 설계 간의 연계를 명확히 나타냅니다.
Verification Path		• Verification Path는 특정 테스트 케이스나 분석 활동이 요구사항을 검증(Verify)하는 관계를 나타내는 경로입니다. • 이 경로는 «verify» 라벨과 함께 점선 화살표로 표시되며, 화살표는 검증 대상인 요구사항을 가리킵니다. • Verification Path는 요구사항이 정의된 대로 구현되었는지 확인하기 위한 테스트나 시뮬레이션 절차를 시각적으로 표현합니다.
Refinement Path		• Refinement Path는 하나의 요구사항이 다른 요구사항이나 모델 요소를 통해 더 구체적이고 세분화된 형태로 정제(Refine)되는 관계를 나타냅니다. • 이 경로는 «refine» 라벨과 함께 점선 화살표로 표시되며, 화살표는 정제된 요구사항을 가리킵니다. • Refinement Path는 고수준의 추상적 요구사항을 명확하고 실질적인 요구사항으로 구체화하는 과정을 표현하며, 설계 및 개발 단계에서 요구사항의 명료성을 높이는 데 사용됩니다.
Trace Path		• Trace Path는 요구사항과 다른 모델 요소(예: 설계 요소, 테스트 케이스, 시스템 구성 요소 등) 간의 일반적인 추적 가능성(Traceability) 관계를 나타냅니다. • 이 경로는 «trace» 라벨과 함께 점선 화살표로 표시되며, 추적 대상이 되는 요소를 가리킵니다. • Trace Path는 특정 요구사항이 설계, 구현, 또는 검증 과정에서 어떻게 반영되고 연결되는지를 시각적으로 표현합니다.
Copy Path		• Copy Path는 하나의 요구사항이 다른 요구사항으로 복사된 관계를 나타냅니다. • 이 경로는 «copy» 라벨과 함께 점선 화살표로 표시되며, 화살표는 복사된 대상 요구사항을 가리킵니다. • Copy Path는 원본 요구사항과 복사된 요구사항 간의 연관성을 명확히 표현하며, 동일하거나 유사한 요구사항을 다른 컨텍스트에서 재사용할 때 사용됩니다.
Trace Callout		• Trace Callout은 요구사항이나 모델 요소와 다른 요소 간의 추적 가능성(Traceability)을 시각적으로 강조하기 위해 사용되는 주석 형태의 요소입니다. • Trace Callout은 요구사항이나 요소 옆에 배치되며, 해당 요소와 연결된 추적 경로(예: «trace», «satisfy», «verify» 등)나 관련 정보를 명확히 나타냅니다.
Derivation Callout		• Derivation Callout은 특정 요구사항이 다른 요구사항으로부터 파생되었음을 명확히 설명하거나 강조하기 위해 사용되는 주석 형태의 요소입니다. • 이는 파생 경로(«derive» 관계)를 시각적으로 표시하고, 관련 정보를 요구사항 옆에 배치하여 요구사항 간의 추적 가능성과 종속성을 한눈에 이해할 수 있도록 합니다. • Derivation Callout은 요구사항의 기원을 명확히 하고, 설계자가 요구사항 개발 과정을 체계적으로 관리하고 검토할 수 있도록 지원합니다.
Verification Callout		• Verification Callout은 특정 요구사항이 테스트, 분석, 시뮬레이션 등을 통해 검증됨을 설명하거나 강조하기 위해 사용되는 주석 요소입니다. • 이 요소는 «verify» 관계를 시각적으로 보완하며, 요구사항 옆에 배치되어 검증 방식, 관련 테스트 케이스, 또는 검증 결과와 같은 세부 정보를 명확히 표시합니다. • Verification Callout은 요구사항 검증 과정을 명확히 이해하고 관리할 수 있도록 도와, 시스템이 요구사항을 충족하는지를 체계적으로 추적하고 검증할 수 있게 합니다.
Satisfaction Callout		• Satisfaction Callout은 특정 요구사항이 시스템 설계나 구성 요소를 통해 충족되고 있음을 강조하거나 설명하기 위해 사용되는 주석 요소입니다. • 이 요소는 «satisfy» 관계를 보완하며, 요구사항 옆에 배치되어 해당 요구사항을 만족시키는 설계 요소나 구현 방식을 명확히 나타냅니다. • Satisfaction Callout은 요구사항 충족 여부를 시각적으로 표현하여 설계자가 요구사항과 구현 간의 연계를 효과적으로 이해하고 관리할 수 있도록 지원합니다.
Refinement Callout		• Refinement Callout은 특정 요구사항이 다른 요구사항이나 모델 요소를 통해 더 구체화되고 정제됨을 설명하거나 강조하기 위해 사용되는 주석 요소입니다. • 이 요소는 «refine» 관계를 보완하며, 요구사항 옆에 배치되어 정제된 세부 사항이나 연관된 모델 요소를 명확히 나타냅니다. • Refinement Callout은 요구사항의 구체화 과정을 시각적으로 표현하여 설계자가 요구사항의 상세화와 관련된 관계를 쉽게 이해하고 관리할 수 있도록 지원합니다.
Master Requirement Callout		• Master Requirement Callout은 특정 요구사항이 다른 요구사항의 주(Master) 요구사항으로 작용함을 설명하거나 강조하기 위해 사용되는 주석 요소입니다. • 이는 요구사항 간의 계층적 관계나 추적 가능성을 명확히 시각화하며, 특히 요구사항이 상위 또는 기준 요구사항에서 파생되었음을 명시할 때 사용됩니다. • Master Requirement Callout은 요구사항 구조와 종속성을 체계적으로 관리하고, 설계자가 상위 요구사항과 하위 요구사항 간의 관계를 명확히 파악할 수 있도록 돕습니다.
Rationale Callout		• Rationale Callout은 특정 요구사항의 이유, 목적, 또는 설계 결정의 배경을 설명하기 위해 사용되는 주석 요소입니다. • 이 요소는 요구사항 옆에 배치되어 해당 요구사항이 왜 필요한지, 어떤 논리적 근거나 맥락에서 도출되었는지를 명확히 나타냅니다. • Rationale Callout은 설계자가 요구사항의 중요성과 정당성을 이해하고, 요구사항의 추적 가능성과 변경 관리를 효과적으로 지원할 수 있도록 합니다.
Problem Callout		• Problem Callout은 특정 요구사항과 관련된 문제점이나 이슈를 명시적으로 설명하기 위해 사용되는 주석 요소입니다. • 이 요소는 요구사항 옆에 배치되어 설계, 구현, 또는 검증 과정에서 발생할 수 있는 잠재적 문제, 충돌, 또는 제약 사항을 시각적으로 나타냅니다. • Problem Callout은 설계자가 요구사항과 관련된 위험 요소를 미리 파악하고, 이를 해결하기 위한 조치를 계획하거나 추적할 수 있도록 지원합니다.