L10-System Modeling (Ch05)

Topics covered

• Context models
• Interaction models
• Structural models
• Behavioral models
• Model-driven engineering 

시스템 모델링

• 시스템 모델링이란 시스템에 대한 다양한 관점을 제시하는 추상적 모델을 개발하는 과정이다.
• 현재는 UML (Unified Modeling Language) 기반의 그래픽 표기법을 사용하여 시스템을 표현한다.
• 이는 시스템 분석가가 시스템의 기능을 이해하는 데 도움을 주며, 고객과의 소통 수단으로 활용된다.

기존 및 계획된 시스템 모델

• 기존 시스템 모델:
  • 요구사항 공학 과정에서 사용됨
  • 시스템이 현재 수행하는 일을 명확히 하는데 도움을 줌
  • 시스템의 강점과 약점 분석의 기초로 사용됨
  • 이는 새로운 시스템의 요구사항 도출로 이어짐
• 새로운 시스템 모델:
  • 요구사항 설명용 시각 자료로 활용됨
  • 이해관계자와의 커뮤니케이션 도구로 사용됨
  • 엔지니어가 이를 통해 설계 제안 논의하고,  시스템 구현 문서로 활용함.
• 모델 기반 엔지니어링 (Model-based Engineering):
  • 시스템 모델로부터 전체 또는 부분적인 시스템 구현이 가능함

시스템 관점

• 외부 관점: 시스템의 맥락 또는 환경을 모델링
• 상호작용 관점: 시스템과 환경 또는 시스템 구성 요소 간의 상호작용 모델링
• 구조적 관점: 시스템의 구성이나 데이터 구조를 모델링
• 행동 관점: 시스템의 동적 행동과 사건에 대한 반응을 모델링

UML 다이어그램 종류

다이어그램 종류	설명
활동 다이어그램	프로세스나 데이터 처리에 포함된 활동(Activity)을 표현
유스케이스 다이어그램	시스템과 외부 환경 간의 상호작용을 표현
시퀀스 다이어그램	행위자(Actor)와 시스템 간, 또는 시스템 구성 요소 간의 상호작용을 표현
클래스 다이어그램	시스템 내 객체 클래스(Class)와 클래스 간의 연관(Relationship) 표현
상태 다이어그램	시스템이 내부 및 외부 사건(Event)에 어떻게 반응하는지 표현

그래픽 모델의 활용

• 논의 촉진 수단:
  • 그래픽 모델은 기존 혹은 제안된 시스템에 대한 논의를 촉진함
  • 불완전하거나 부정확한 모델도 의사소통 도구로서 유용하며 허용됨
• 기존 시스템 문서화:
  • 모델은 시스템을 정확히 표현해야 하나, 완전할 필요는 없음
• 시스템 구현 설명:
  • 시스템 구현 생성을 위한 모델은 정확하고 완전해야 함

 

[1] 컨텍스트 모델 (Context models)

컨텍스트 모델

 

• 컨텍스트 모델: 시스템의 운영 환경을 시각화하기 위해 사용되며, 시스템 경계 밖의 요소들을 나타냄
• 시스템 경계: 시스템 내부와 외부를 정의하며, 다른 시스템과의 의존 관계를 보여줌
  • 시스템 경계의 위치는 시스템 요구사항에 큰 영향을 미침
  • 시스템 경계 정의는 정치적 판단일 수 있음
    • 예: 부서 간 업무량 조정 또는 영향력 확대/축소 목적
• 아키텍처 모델: 시스템과 다른 시스템들과의 관계를 나타냄

 

예시 : Mentcare 시스템의 컨텍스트

 

시스템 이름	역할 설명
Patient record system	환자의 진료 기록을 관리함
Admissions system	입원 관련 정보를 관리함
Prescription system	처방전 정보를 관리함
Appointments system	진료 예약을 관리함
HC statistics system	보건 통계 데이터를 관리함
Management reporting system	경영 보고를 위한 시스템

• 즉, Mentcare는 병원 내 다양한 기능(진료 기록, 예약, 처방 등)을 각각의 시스템과 연결해서 통합적으로 작동하게 도와주는 중심 시스템이다.

프로세스 관점

 

• 컨텍스트 모델: 다른 시스템을 보여주지만, 개발 중인 시스템이 어떻게 사용되는지는 설명하지 않음
• 프로세스 모델: 개발 중인 시스템이 비즈니스 프로세스 내에서 어떻게 사용되는지를 설명
  • 예: 강제 입원 프로세스 모델
• UML 활동 다이어그램(Activity Diagram): 비즈니스 프로세스를 정의하는 데 사용

 

예시 : 강제 입원 프로세스 모델

단계	설명
Confirm detention decision	환자를 입원시킬지 결정함
Inform patient of rights	환자에게 자신의 권리를 알려줌
Record detention decision	결정된 사항을 Mentcare 시스템에 기록함
Find secure place	보호가 가능한 장소를 찾음
Transfer to police station / secure hospital	장소가 없으면 경찰서로, 있으면 보호병원으로 이송함
Admit to hospital	위험하지 않다면 병원에 입원시킴 (Admissions system에 기록)
Inform social care / next of kin	사회복지 서비스나 보호자에게 상황을 알림
Update register	Mentcare 시스템에 최종 기록을 갱신함

• 이 흐름은 ‘강제로 입원’이라는 민감한 절차를 어떻게 체계적으로 처리하는지를 보여준다.

 

 

 

[2] 상호작용 모델 (Interaction models)

상호작용 모델

• 사용자 상호작용 모델링: 사용자 요구사항을 식별하는 데 도움이 됨
• 시스템 간 상호작용 모델링: 통신 문제를 사전에 파악할 수 있음
• 구성 요소 간 상호작용 모델링: 시스템 구조가 성능과 신뢰성을 충족하는지 이해하는 데 도움
• 사용되는 도구: 유스케이스 다이어그램 (Use case diagram), 시퀀스 다이어그램 (Sequence diagram)

유스케이스 모델링

 

• 원래는 요구사항 도출을 위한 도구였으며, 현재는 UML에 통합됨
• 유스케이스 (Use case): 시스템과 외부 간의 개별 작업
• 행위자 (Actor): 사람이 될 수도 있고 다른 시스템일 수도 있음
• 표현 방식: 다이어그램 + 텍스트

 

Transfer-data 유스케이스

• Mentcare 시스템 내의 유스케이스

간단한 유스케이스

• 의료 접수자(Medical receptionist)가 환자 기록 시스템(Patient record system)으로
• "Transfer data"(데이터 전송) 작업을 수행하는 기본적인 흐름을 보여줌

‘Transfer data’ 유스케이스의 표 형식 설명

• MHC-PMS: Transfer data

행위자	의료 접수자, 환자 기록 시스템 (PRS)
설명	접수자는 Mentcare 시스템에서 보건 당국이 관리하는 일반 환자 기록 데이터베이스로 데이터를 전송할 수 있다. 전송되는 정보는 업데이트된 개인정보(주소, 전화번호 등)나 환자의 진단 및 치료 요약일 수 있다.
데이터	환자의 개인정보, 치료 요약
자극	의료 접수자가 발행한 사용자 명령
반응	PRS가 업데이트되었음을 확인
비고	접수자는 환자 정보와 PRS에 접근할 수 있는 적절한 보안 권한을 가지고 있어야 한다.

Mentcare 시스템 내에서 ‘의료 접수자’ 역할이 포함된 유스케이스

: 이 다이어그램은 의료 접수자(Medical receptionist)가 Mentcare 시스템에서 수행할 수 있는 주요 기능을 보여준다

• 환자 등록(Register patient)
• 환자 등록 취소(Unregister patient)
• 환자 정보 조회(View patient info)
• 데이터 전송(Transfer data)
• 환자 연락(Contact patient)

시퀀스 다이어그램

 

• UML 구성 요소 중 하나
• 행위자와 시스템 객체 간의 상호작용을 순서대로 표현
• 다이어그램 구성:
  • 상단: 행위자, 객체 나열
  • 아래로: 수직 점선
  • 상호작용: 주석이 달린 화살표
• 예시: 환자 정보 조회 시퀀스 다이어그램

 

환자 정보 조회 시퀀스 다이어그램

환자 정보 조회 프로세스

• 의료 접수자가 환자 정보(PID)를 요청
• Mentcare-DB에 정보와 사용자 ID를 보고
• 권한 시스템(Authorization)을 통해 접근 권한 확인
• 권한이 있으면 환자 정보 제공, 없으면 접근 오류 메시지 표시

데이터 전송 시퀀스

• 의료 접수자와 PRS(환자 기록 시스템) 간의 상호작용
• 환자 정보 업데이트 및 요약정보 업데이트 과정 포함
• 권한 확인 단계를 거쳐 데이터가 전송되는 흐름 표시
• 로그인/로그아웃 과정도 포함

 

 

 

[3] 구조 모델 (Structural models)

구조 모델

• 소프트웨어의 구조 모델은 시스템을 구성하는 컴포넌트들과 그들 간의 관계를 통해 시스템의 구성을 보여준다.
• 구조 모델은 시스템 설계를 보여주는 정적 모델(static models)일 수도 있고, 실행 중인 시스템의 구성을 보여주는 동적 모델(dynamic models)일 수도 있다.
• 시스템 아키텍처를 논의하고 설계할 때 구조 모델을 생성한다.

클래스 다이어그램

• 객체 지향 시스템 모델을 개발할 때 사용되며, 시스템 내의 클래스들과 이들 간의 연관 관계를 보여준다.
• 객체 클래스는 시스템 객체의 일반적인 정의로 볼 수 있다.
• 연관(association)은 클래스 간에 어떤 관계가 존재함을 나타내는 연결이다.
• 모델을 개발할 때 객체는 현실 세계의 개체(예: 환자, 처방전, 의사)를 나타낸다.

→ UML 클래스와 연관, MHC-PMS의 클래스와 연관, Consultation 클래스

UML 클래스와 연관

• Patient(환자)와 Patient record(환자 기록) 사이에 1:1 관계가 있음
• 각 환자는 정확히 하나의 환자 기록을 가지며, 각 환자 기록은 정확히 하나의 환자에 속함

MHC-PMS의 클래스와 연관

 

• Patient(환자)가 중심이 되는 관계도
  • Patient와 Condition(상태) 사이에 "diagnosed-with"(진단됨) 관계
    : 환자는 0개 이상의 상태로 진단받을 수 있음(1..*)
  • Patient와 Consultant(전문의) 사이에 "referred-to"(의뢰됨) 관계
    : 환자는 0개 이상의 전문의에게 의뢰될 수 있음(1..*)
  • Patient와 General practitioner(일반의) 사이에 "referred-by"(의뢰함) 관계
    : 환자는 정확히 하나의 일반의에 의해 의뢰됨
  • Patient와 Consultation(진료) 사이에 "attends"(참석) 관계
    : 환자는 0개 이상의 진료에 참석함(1..*)
  • Consultation과 Hospital Doctor(병원 의사) 사이에 "runs"(진행) 관계
    : 진료는 1~4명의 의사에 의해 진행됨
  • Consultation과 Medication(약물) 사이에 "prescribes"(처방) 관계
    : 진료에서 0개 이상의 약물을 처방할 수 있음
  • Consultation과 Treatment(치료) 사이에 "prescribes"(처방) 관계
    : 진료에서 0개 이상의 치료를 처방할 수 있음

 

Consultation 클래스

속성(Attributes):

• Doctors(의사들)
• Date(날짜)
• Time(시간)
• Clinic(클리닉)
• Reason(이유)
• Medication prescribed(처방된 약물)
• Treatment prescribed(처방된 치료)
• Voice notes(음성 메모)
• Transcript(기록)
• ...(기타)

메소드(Methods):

• New()(새로 만들기)
• Prescribe()(처방하기)
• RecordNotes()(메모 기록)
• Transcribe()(기록하기)
• ...(기타)

-> 이 다이어그램들은 의료 정보 시스템에서 환자, 의사, 진료, 치료 등의 관계를 UML 클래스 다이어그램으로 표현한 것이다

일반화 (Generalization)

• 복잡성 관리를 위한 일반적인 기법
• 다양한 개체를 더 일반적인 클래스(예: 동물, 자동차, 집)로 분류
• 동일 클래스 구성원의 공통된 특성 추론 가능 (예: 다람쥐와 쥐는 둘 다 설치류)
• 시스템 모델링 시 클래스 간 일반화의 가능성 확인 중요
• 변경이 제안되면 상위 클래스만 확인하면 됨
• Java 등의 객체지향 언어에서는 상속 메커니즘으로 구현
• 상위 클래스의 속성과 연산은 하위 클래스에 적용
• 하위 클래스는 상속받은 속성에 자체 속성을 추가 가능

→ 일반화 계층 구조, 세부 정보가 추가된 일반화 계층 구조

일반화 계층 구조

 

• 의사(Doctor) 클래스를 최상위로 하는 계층적 상속 구조를 보여줌
• Doctor는 Hospital doctor(병원 의사)와 General practitioner(일반의)로 구분됨
• Hospital doctor는 다시 Consultant(전문의)와 Team doctor(팀 의사)로 나뉨
• Team doctor는 Trainee doctor(수련의)와 Qualified doctor(자격 있는 의사)로 세분화됨
• 이는 UML의 일반화(상속) 관계를 나타내는 계층도

 

세부 정보가 추가된 일반화 계층 구조

 

: 상단 다이어그램의 기본 구조를 유지하되, 각 클래스의 속성과 메소드가 추가됨

Doctor 클래스:

• 속성: Name(이름), Phone #(전화번호), Email(이메일)
• 메소드: register()(등록), de-register()(등록 취소)

Hospital doctor 클래스:

• 속성: Staff #(직원 번호), Pager #(페이저 번호)

General practitioner 클래스:

• 속성: Practice(진료소), Address(주소)

 

객체 클래스 집합(aggregation) 모델

• 집합 모델은 집합 클래스가 다른 클래스들로 구성되는 방식
• 의미론적 데이터 모델에서의 part-of 관계와 유사함

→ 집합 연관

집합 연관

 

: Patient record(환자 기록)를 중심으로 한 집합 관계 다이어그램

• Patient record는 정확히 하나의 Patient(환자)와 연결됨(1:1 관계)
• Patient record는 여러 개의 Consultation(진료)와 연결될 수 있음(1:다 관계, 1..*)
• 다이아몬드 표시는 집합 관계를 나타내며, Patient record가 Patient와 Consultation을 포함하는 개념적 전체를 의미함
• 환자 기록은 환자 정보와 해당 환자의 모든 진료 기록을 집합한 형태로 구성됨을 보여줌

 

 

 

 

[4] 행위 모델 (Behavioral models)

행위 모델

 

• 시스템이 실행될 때의 동작을 모델링
• 시스템이 외부 자극에 반응하여 어떻게 동작하는지 또는 어떻게 동작해야 하는지를 보여줌
• 자극의 유형
  • 데이터: 시스템이 처리해야 할 데이터가 도착
  • 이벤트: 사건 발생이 시스템 처리를 유발 (관련 데이터가 있을 수도, 없을 수도 있음)

 

데이터 기반 모델링 (Data-driven modeling)

• 데이터 중심으로 작동하는 데이터 처리 시스템에 적합
• 입력 데이터에 의해 제어됨
• 입력 → 처리 → 출력의 작업 순서를 표현
• 요구사항 분석 시 유용하며, 시스템의 end-to-end 처리 과정을 보여줄 수 있음

→ 예시: 인슐린 펌프 작동, 주문 처리

예시 : 인슐린 펌프 작동의 활동 모델

 

• 혈당 측정 및 인슐린 주입 과정의 활동 흐름을 보여주는 다이어그램
• 프로세스 흐름:
  1. Blood sugar sensor(혈당 센서) → Get sensor value(센서 값 획득) → Sensor data(센서 데이터) → Compute sugar level(혈당 수치 계산) → Blood sugar level(혈당 수치)
  2. Blood sugar level → Calculate insulin delivery(인슐린 투여량 계산) → Insulin requirement(인슐린 요구량) → Calculate pump commands(펌프 명령 계산) → Pump control commands(펌프 제어 명령) → Control pump(펌프 제어) → Insulin pump(인슐린 펌프)
• 이는 당뇨병 환자를 위한 자동 인슐린 펌프 시스템의 작동 흐름을 나타냄

 

예시 : 주문 처리

 

• Purchase officer(구매 담당자)와 Supplier(공급자) 간의 주문 처리 과정
• 주요 프로세스:
  1. 구매 담당자가 주문서(Order) 작성(FillIn 메소드)
  2. 주문 유효성 검증(Validate 메소드)
  3. 검증 성공 시 예산(Budget) 업데이트(Update 메소드)
  4. 주문 데이터 저장소(Orders datastore)에 저장(Save 메소드)
  5. 공급자에게 주문 전송(Send 메소드)
• 시스템 내 객체 간 상호작용과 메시지 흐름을 UML 시퀀스 다이어그램으로 표현

 

이벤트 기반 모델링 (Event-driven modeling)

• 실시간 시스템은 이벤트 기반으로 동작
• 데이터 처리 최소화, 주로 이벤트에 반응
• 예: 유선 전화 시스템에서 '수화기 들기' → 발신음 발생
• 시스템이 외부/내부 이벤트에 어떻게 반응하는지 보여줌
• 시스템은 유한한 상태를 가지며, 이벤트에 의해 상태 전이 발생

상태 기계 모델 (State machine models)

• 시스템의 동작 반응을 상태와 전이로 모델링
• 실시간 시스템에 자주 사용됨
• 구성 요소:
  • 상태 = 노드
  • 이벤트 = 노드 간 호(arc)
  • 이벤트 발생 시 한 상태 → 다른 상태로 전이
• UML의 상태 차트(Statecharts)로 표현

→ 예시: 전자레인지의 상태 다이어그램

전자레인지의 상태 다이어그램

 

• 전자레인지의 다양한 상태와 상태 전이를 보여주는 UML 상태 다이어그램
• 상태 전이 조건: Full power, Half power, Timer, Door open, Door closed, Start, Cancel 등
• 각 상태에서 수행하는 작업(do: 작업)이 명시됨

 

 

전자레인지 작동

• 전자레인지 작동 과정의 세부 상태를 보여주는 다이어그램
• 상태 전이 조건: OK, Turntable fault(턴테이블 오류), Emitter fault(발열체 오류), Timeout, Door open, Cancel
• 외부 상태로 전이: Disabled, Waiting

전자레인지의 상태와 자극

상태	설명
대기	입력 대기 중, 화면에 현재 시간 표시
반출력	전력 300와트로 설정, '반출력' 표시
전출력	전력 600와트로 설정, '전출력' 표시
시간 설정	사용자 입력에 따라 조리 시간 설정, 화면 업데이트
사용 불가	안전 비활성화, 조명 켜짐, '준비되지 않음' 표시
사용 가능	작동 가능, 조명 꺼짐, '조리 준비됨' 표시
조리 중	조리 진행, 조명 켜짐, 타이머 카운트다운, 완료 시 부저 5초 울림

자극	설명
반출력	반출력 버튼 누름
전출력	전출력 버튼 누름
타이머	타이머 버튼 누름
숫자	숫자 키 입력
문 열림	문 스위치가 열림
문 닫힘	문 스위치가 닫힘
시작	시작 버튼 누름
취소	취소 버튼 누름

 

 

 

[5] 모델 기반 공학 (Model-driven engineering)

모델 기반 공학

• 모델 기반 공학(MDE)은 소프트웨어 개발에서 프로그램이 아닌 모델이 개발 과정의 주요 산출물이 되는 접근 방식이다.
• 하드웨어/소프트웨어 플랫폼에서 실행되는 프로그램은 이 모델로부터 자동으로 생성된다.
• MDE 지지자들은 이 방식이 소프트웨어 공학의 추상화 수준을 높여서, 개발자가 더 이상 프로그래밍 언어나 실행 플랫폼의 세부사항에 신경 쓰지 않아도 된다고 주장한다.

모델 기반 공학의 활용

• 모델 기반 공학은 아직 초기 단계에 있으며, 소프트웨어 공학 실무에 큰 영향을 미칠지는 확실하지 않다.
• 장점
  • 시스템을 더 높은 수준의 추상화로 다룰 수 있다.
  • 코드를 자동으로 생성하면, 새로운 플랫폼에 시스템을 적응시키는 비용이 저렴해진다.
• 단점
  • 추상화를 위한 모델이 실제 구현에 적합하지 않을 수 있다.
  • 코드 생성을 통해 얻는 비용 절감이 새로운 플랫폼용 변환기(translator) 개발 비용보다 클 것이라는 보장이 없다.

모델 기반 아키텍처

• 모델 기반 아키텍처(MDA)는 보다 일반적인 모델 기반 공학의 전신이다.
• MDA는 UML 모델의 일부를 사용하여 시스템을 기술하는 모델 중심의 소프트웨어 설계 및 구현 접근 방식이다.
• 서로 다른 추상화 수준의 모델들이 생성된다. 고수준의 플랫폼 독립 모델(PIM)로부터, 원칙적으로는 수동 작업 없이 작동하는 프로그램을 생성할 수 있다.

모델의 종류

• 계산 독립 모델 (CIM)
  • 시스템에서 사용되는 중요한 도메인 추상화를 모델링한다. CIM은 종종 도메인 모델이라고 불린다.
• 플랫폼 독립 모델 (PIM)
  • 시스템의 동작을 구현에 관계없이 모델링한다. 일반적으로 UML 모델을 사용하여 정적 구조와 시스템이 외부 및 내부 이벤트에 어떻게 반응하는지를 표현한다.
• 플랫폼 종속 모델 (PSM)
  • PIM을 플랫폼에 맞게 변환한 모델로, 각 애플리케이션 플랫폼에 대해 별도의 PSM이 존재한다. 원칙적으로는 PSM도 여러 계층으로 나뉘며, 각 계층은 플랫폼에 특화된 세부 정보를 추가한다.

MDA 변환 과정

다중 플랫폼 종속 모델

애자일 방법론과 MDA

• MDA의 개발자들은 MDA가 반복적인 개발 방식을 지원하도록 설계되었으며, 따라서 애자일 방법론과 함께 사용할 수 있다고 주장한다.
• 하지만 광범위한 사전 모델링이라는 개념은 애자일 선언문의 핵심 아이디어와 모순되며, 대부분의 애자일 개발자들은 모델 기반 공학에 익숙하지 않거나 불편함을 느낀다.
• 변환이 완전히 자동화되어 PIM으로부터 완전한 프로그램을 생성할 수 있다면, 원칙적으로는 별도의 코딩 없이 애자일 개발 프로세스에 MDA를 활용할 수 있다.

MDA의 채택 현황

• 여러 요인이 MDE/MDA의 채택을 제한해왔다.
• 모델 간 변환을 위해 특화된 도구가 필요하다.
• 사용 가능한 도구가 제한적이며, 조직 환경에 맞게 도구를 수정하거나 맞춤화해야 할 수 있다.
• MDA로 개발된 장수 시스템의 경우, 기업은 자체 도구를 개발하거나 폐업 가능성이 있는 소규모 기업의 도구에 의존하는 것을 꺼린다.
• 모델은 소프트웨어 설계 논의를 촉진하는 데는 유용하지만, 실제 구현에는 적절하지 않은 추상화를 포함할 수 있다.
• 대부분의 복잡한 시스템에서는 구현보다 요구사항 분석, 보안 및 신뢰성, 레거시 시스템과의 통합, 테스트 등의 문제가 더 중요하다.
• 플랫폼 독립성의 필요성은 크고 장기적인 시스템에만 해당된다. 일반적인 소프트웨어 제품이나 정보 시스템에서는 MDA 도입과 도구 구축에 드는 비용이 절감 효과를 상쇄할 수 있다.
• MDA가 발전하던 시기와 동시에 애자일 방법론이 널리 채택되면서, 모델 기반 접근 방식에 대한 관심이 줄어들었다.

핵심 요점

• 모델은 시스템의 세부사항을 생략한 추상적인 관점이다. 시스템의 문맥, 상호작용, 구조, 행동을 보여주는 보완적인 모델들이 개발될 수 있다.
• 문맥 모델(Context model)은 시스템이 다른 시스템이나 프로세스와 함께 환경 내에서 어떻게 위치하는지를 보여준다.
• 유스케이스 다이어그램과 시퀀스 다이어그램은 사용자가 시스템과 상호작용하는 방식을 설명한다. 유스케이스는 시스템과 외부 행위자 간의 상호작용을 기술하며, 시퀀스 다이어그램은 시스템 객체 간의 상호작용을 추가로 보여준다.
• 구조 모델은 시스템의 조직과 아키텍처를 보여준다. 클래스 다이어그램은 시스템 내 클래스들의 정적인 구조와 연관을 정의하는 데 사용된다.
• 행위 모델은 실행 중인 시스템의 동작을 설명하는 데 사용된다. 이는 시스템이 처리하는 데이터 관점이나 시스템 반응을 유도하는 이벤트 관점으로 모델링될 수 있다.
• 액티비티 다이어그램은 데이터 처리 흐름을 모델링하며, 각 액티비티는 하나의 처리 단계를 나타낸다.
• 상태 다이어그램은 시스템이 내부 또는 외부 이벤트에 반응하는 행동을 모델링하는 데 사용된다.
• 모델 기반 공학은 시스템을 일련의 모델로 표현하고, 이를 자동 변환하여 실행 가능한 코드로 만드는 소프트웨어 개발 접근 방식이다.