로봇 소프트웨어 아키텍처 모델링

• 아키텍처 모델링 = 복잡한 시스템 구조를 추상화한 모델(그림·문서) 로 표현하는 활동
• 건물의 평면도·배관도·전기도가 서로 다른 관점이듯, 소프트웨어도 여러 뷰(View) 로 나눠 그림
• 시험 출제 포인트: 품질 속성(비기능 요구)이 아키텍처를 결정한다는 원리, 4+1 뷰 모델의 다섯 뷰 매칭, UML 주요 다이어그램의 용도

무엇이 아키텍처를 결정하는가 — 아키텍처 드라이버

• 기능 요구("서빙을 한다")는 어떤 구조로도 구현 가능

• 구조를 실제로 결정하는 것은 품질 속성(Quality Attribute, 비기능 요구)

• 성능·실시간성: 제어 주기 1 ms → 실시간 계층 분리 필수

• 확장성: 로봇 10대 → 100대 → 분산·서버 구조

• 가용성·안전성: 노드 하나가 죽어도 정지 금지 → 장애 격리 구조, 감시(watchdog)

• 수정 용이성: 센서 교체가 잦다 → 드라이버 계층 분리

• 보안성: 원격 접속 → 인증·암호화 계층

• 아키텍처 설계에 큰 영향을 주는 요구(핵심 기능 + 품질 속성 + 제약사항) = 아키텍처 드라이버(Architecture Driver) — 요구사항 분석 단계에서 이를 식별하는 것이 모델링의 출발점

• 품질 속성은 "빨라야 한다"가 아니라 측정 가능한 시나리오("최대 부하에서 회피 반응 100 ms 이내")로 구체화

뷰(View) — 하나의 그림으로는 부족하다

• 복잡한 시스템은 관점별로 나눠 그림
• 대표 프레임워크 = 4+1 뷰 모델(Kruchten) (시험 단골)

로봇 예: 논리 뷰(인지·계획·제어 모듈), 프로세스 뷰(노드와 토픽 연결 — ROS 계산 그래프가 사실상 이것), 물리 뷰(주 컴퓨터·MCU·클라우드 배치).

모델링 언어 — UML

• UML(Unified Modeling Language) = SW 구조·행위를 그리는 표준 표기법

• 구조와 행위로 나뉨 (상세 문법은 객체지향 소프트웨어 설계)

• 구조(정적): 클래스(타입과 관계), 컴포넌트(모듈과 인터페이스), 배치(HW 노드 위 SW 배치)

• 행위(동적): 유스케이스(기능 조망), 순서(객체 간 메시지의 시간 순서), 상태(상태와 전이 — FSM), 활동(작업 흐름·순서도)

시스템 전체(HW 포함)를 다루는 확장으로 SysML이 있다 — 로봇처럼 HW·SW가 얽힌 시스템 공학에 사용된다.

로봇 특화 모델 — 계산 그래프

• 미들웨어 기반 로봇 SW는 노드(프로세스)와 메시지 흐름의 그래프로 모델링하는 것이 실용 표준 (→ 로봇 미들웨어 구조 설계)
• 노드·토픽·서비스의 연결도는 4+1의 프로세스 뷰에 해당 — 실행 중 실제 그래프를 시각화해 설계 모델과 대조 가능 (→ 로봇 소프트웨어 개발환경)

아키텍처 모델링 절차

1. 요구 분석: 기능·품질 속성·제약 수집 (시나리오-기술 매핑이 입력)
2. 아키텍처 드라이버 식별: 구조를 결정할 소수 핵심 요구 선정
3. 구조 후보 설계: 스타일 선택(→ 로봇 소프트웨어 아키텍처 분류), 모듈 분할·인터페이스 정의
4. 뷰 문서화: 4+1 뷰 기준으로 다이어그램·설명 작성
5. 평가·검증: 드라이버 충족 여부 평가 (→ 로봇 소프트웨어 아키텍처 검증)

모델은 의사소통 도구다 — 완벽한 그림보다, 이해관계자가 같은 구조를 상상하게 만드는 것이 목적이다.

4+1 뷰 모델

flowchart TD
    UC["유스케이스 뷰 (+1)
시나리오로 전체 검증"]
    L["논리 뷰
기능·클래스 구조"] --- UC
    P["프로세스 뷰
동시성·노드·통신"] --- UC
    D["개발 뷰
패키지·코드 구성"] --- UC
    PH["물리 뷰
HW 배치"] --- UC

아키텍처 모델링 절차

flowchart LR
    R["① 요구 분석"] --> AD["② 드라이버 식별
(품질 속성 시나리오)"] --> C["③ 구조 후보 설계"] --> V["④ 뷰 문서화
(4+1·UML)"] --> E["⑤ 평가·검증"]
    E -- 미충족 시 재설계 --> C

1. 소프트웨어 아키텍처를 실질적으로 결정하는 요인으로 가장 적절한 것은?

① 기능 요구사항의 개수 ② 품질 속성(비기능 요구)과 제약사항 ③ 개발 언어의 문법 ④ 소스 코드의 줄 수

2. 4+1 뷰 모델에서 프로세스·스레드의 동시성과 통신 구조를 다루는 뷰는?

① 논리 뷰 ② 프로세스 뷰 ③ 개발 뷰 ④ 물리 뷰

3. 소프트웨어 구성요소를 어느 하드웨어(컴퓨터·제어기)에 배치하는지 표현하는 UML 다이어그램은?

① 클래스 다이어그램 ② 순서 다이어그램 ③ 배치(Deployment) 다이어그램 ④ 상태 다이어그램

4. 품질 속성 요구의 기술 방식으로 가장 적절한 것은?

① "시스템은 빨라야 한다" ② "시스템은 사용하기 좋아야 한다" ③ "최대 부하 상태에서 장애물 회피 반응이 100 ms 이내여야 한다" ④ "시스템은 최신 기술을 사용해야 한다"

5. 아키텍처 모델링 절차의 순서로 옳은 것은?

① 뷰 문서화 → 요구 분석 → 구조 설계 → 평가 ② 요구 분석 → 드라이버 식별 → 구조 후보 설계 → 뷰 문서화 → 평가·검증 ③ 구조 설계 → 드라이버 식별 → 요구 분석 → 평가 ④ 평가 → 구조 설계 → 뷰 문서화 → 요구 분석

• 로봇 소프트웨어 아키텍처 분류 — 구조 후보가 되는 스타일들
• 객체지향 소프트웨어 설계 — UML 다이어그램 상세
• 로봇 소프트웨어 아키텍처 검증 — 모델의 평가·검증
• 로봇 소프트웨어 구조 설계 — 미들웨어 관점의 구조 설계
• 작업 시나리오별 소프트웨어 구현기술 — 모델링의 입력
• _MOC 로봇소프트웨어구조설계