2-3-2 로봇 작업 요구사항 분석 2/2

도메인 분석

요구 사항 추출 이후에는 요구들을 바탕으로 한 도메인 분석 단계로 진행한다. 도메인이란 해당 소프트웨어의 적용 범위 또는 동작 범위를 말한다. 그러므로 도메인 분석이란 로봇 소프트웨어가 적용되는 범위와 관련된 요구들의 배경과 환경을 분석하여 개발자와 고객 간의 공통 개념을 세워가는 과정에 해당된다. 도메인 분석에는 도메인에서 사용되는 개념들을 정리한 도메인 사전, 시스템에서 반드시 사용해야 하는 공식이나 시스템의 사용 규칙 등을 정리한 비즈니스 규칙이 포함된다.

 

• 도메인 사전

고객과 개발자 간의 의사소통을 위하여 도메인 내에서 사용되는 용어들을 정의할 필요가 있다. 용어 사전의 내용은 쉽고 정확하여야 한다. 용어 사전을 구성하는 구성 요소는 명칭, 타입, 설명 또는 예시이다.
(1) 명칭
각각의 명칭들은 사용되는 개념들에 대한 식별자이다. 일반적인 사전에서와 같이 하나의 명칭은 여러 가지의 의미를 가질 수 있다. 국어사전의 단어라고 보면 된다.
(2) 타입
각각의 명칭들은 사용되는 개념들에 대한 식별자이다. 일반적인 사전에서와 같이 하나의 명칭은 여러 가지의 의미를 가질 수도 있고, 명사, 동사 등 쓰임새가 다를 수도 있다. 타입은 기능, 역할, 개념, 기기, 사람 등으로 분류한다.
(3) 설명 또는 예시
용어를 정확하게 설명하기 위하여 사용되는 예시나 추가 설명을 기입하면 좋다.

 

• 비즈니스 규칙

 

비즈니스 규칙이란 해당 시스템이 동작하는 데 있어서 반드시 지켜져야 할 규칙, 정책을 말한다. 비즈니스 규칙은 고객, 매뉴얼, 업무 지시서, 전문가 인터뷰 등을 통하여 수집 된다. 비즈니스 규칙이 일목요연하게 관리되어 있지 않으면, 개발자가 규칙을 나중에 발견하게 되었을 경우 많은 수정 작업을 거쳐야 할 수도 있다. 또 문서화되어 있지 않은 여러 가지 비즈니스 규칙을 잘 아는 기존의 개발자가 퇴사를 하여 개발자가 바뀌는 경우에도, 새로운 개발자는 로봇 소프트웨어에 녹아 들어있는 비즈니스 규칙을 이해하고 파악하기 위하여 많은 시간 투자를 해야 할 것이다.

 

사용 사례 

 

• 사용 사례

 

성공적으로 개발된 로봇 소프트웨어는 사용자의 요구 사항을 모두 반영하여야 한다. 사용 자의 요구 사항은 말, 그림, 매뉴얼, 기존의 유사 시스템, 개발 요구서, 사용 사례 등을 통하여 개발자에게 전달된다. 개발자는 사용자의 요구 사항을 분석하여 시스템이 제공해야할 기능들을 구현하고, 구현된 기능들을 확인하는 일을 하게 된다. 개발 요구서가 정확하게 주어지지 않는 한 개발자는 사용자의 요구 사항을 분석하기 위하여 여러 방법을 사용한다. 사용 사례란 시스템이 수행할 것으로 기대되는 기능을 말한다. 사용 사례는 사용자 또는 외부 시스템이나 기타 요소들이 시스템과 상호 작용하는 흐름을 모델링한 것이다. 사용 사례가 중요한 이유는 [그림 1]과 같이 시스템 개발을 시작하는 요구 분석 단계에서부터 설계 단계를 거쳐 테스팅에 이르기까지 꼭 필요한 길잡이라고 할수 있다. 즉 모델링 단계에서는 기능적 모델링을 할 수 있는 단초를 제공해 주며, 설계 단계에서는 상세한 설계 구성 요소가 되며, 테스팅 단계에서는 테스트 시나리오로 사용할수 있기 때문이다.

 

[그림 1] 사용 사례의 적용 범위

 

사용 사례에서 시스템과 상호 작용하는 객체를 액터(actor)라 한다. 각 사용 사례는 외부 객체들이 시스템과 어떻게 상호 작용하는지 가능한 시나리오를 나타내는 것이다. 사용 사례는 관련된 액터와 함께 시스템이 어떻게 기능하는지를 텍스트 형태로 기술할 수도 있다. 각 사용 사례에 대하여 발생할 수 있는 모든 이벤트를 순서대로 파악하고 이에 대한 시스템의 반응들을 나열한다. 시스템 밖에 있는 요소들이 시스템을 사용하는 사용 사례를 모두 모으면 시스템의 기능을 설명하는 것이 될 것이다. 개발자는 사용 사례를 분석하여 사용자의 요구 사항을 정리하고, 이를 바탕으로 구현되어야 할 기술 내용을 결정할 수 있다. 시스템의 구현이 잘 되었는지를 평가하기 위하여 각각의 사용 사례를 이용하여 시스템의 동작을 확인한다.
사용 사례는 충분히 많이 작성하여야 하며, 개발자가 로봇 소프트웨어를 만들 때에 고려된 적이 없는 상황이 생기지 않도록 하여야 한다. 그러므로 사용자가 해당 시스템을 사용할 때에 생길 수 있는 모든 상황들을 기술할 수 있도록 노력하여야 한다.

 

• 사용 사례의 용어 

 

(1) 액터
액터(actor)란 시스템과 작용하는 외부의 객체로서, 사람 또는 다른 시스템이다. 재난 구조용 모바일 로봇의 예를 들어보자. 액터가 사람인 예는 모바일 로봇을 감시하거나 제어하는 사용자가 될 수 있다. 액터가 사물인 예는 움직이거나 정지해 있는 장애물이될 수 있다. 액터가 시스템인 경우는 두 대의 모바일 로봇이 상호 협력 작업을 해야 되는 경우에서 상대 모바일 로봇이 될 수 있다.
(2) 시나리오
시나리오는 사용자의 관점에서 액터와 시스템 사이에 일어나는 일들을 기술한 것이다. 여러 가지 시나리오들을 분석하여 일반화된 사용 사례를 찾는다. 시나리오는 정상적인 흐름 외에도 오류, 특정한 장소와 시간 등의 예외적인 흐름도 포함한다.

(3) 사용 사례
사용 사례는 하나의 시나리오 또는 여러 개의 시나리오를 종합하여 일반화한 것이다. 사용 사례는 개발자와 고객 간의 의사소통 수단이다. 예외적인 사건의 흐름에 대하여 개발자가 알 수 있게 하고, 개발된 시스템의 기능에 대하여 고객이 알 수 있게 된다.

 

• 사용 사례의 표현

 

사용 사례 다이어그램은 시스템의 기능을 쉽게 알아볼 수 있도록 사용 사례를 그림으로 나타낸 것이다. 시스템이 커지면 커질수록 각각의 사용 사례들은 중복되거나 복잡해지는 데, 사용 사례 다이어그램은 이런 문제를 해결하는 데 도움이 된다. 사용 사례 다이어그램은 액터, 사용 사례, 관계의 세 가지로 구성된다. 사용 사례 다이어그램은 사용 사례를 액터의 관점에서 기술하고, 시스템 내부의 동작이 아닌 액터와 사용 사례의 상호 작용을 나타내는 것이 좋다.

(1) 액터
작업을 수행하기 위하여 시스템의 지원을 받는 객체는 액터가 될 수 있다. 시스템의 주요 기능을 사용하는 객체는 액터가 될 수 있다. 유지보수와 관리 같은 부수적인 기능을 사용하는 객체는 액터가 될 수 있다. 다른 외부 하드웨어나 소프트웨어와 연결되어 동작한다면 그 시스템은 액터가 될 수 있다. [그림 2]는 액터의 예를 나타낸다.

 

[그림 2] 액터의 예

(2) 사용 사례
사용 사례 다이어그램의 사용 사례는 시스템이 제공하는 기능이나 서비스이다. 사용 사례는 액터의 입장에서 보는 시스템의 동작을 기술한 것이다. [그림 3]은 사용 사례의 예를 나타낸다. 사용자가 원격 모니터링 및 제어 장치를 이용하여 위험 상황을 감지하고 정지 버튼을 누르는 기능을 사용 사례의 예라 할 수 있다.

 

[그림 3] 사용 사례의 예

 

(3) 관계 

(가) 연결 관계
액터와 상호 작용하는 사용 사례는 실선 화살표로 연결된다. 하나의 액터는 복수의 사용 사례와 연결할 수 있다. [그림 4]는 액터와 사용 사례의 연결 관계를 나타내고 있다.

 

[그림 4] 연결 관계의 예

 

 

(나) 포함관계
여러 개의 사용 사례에서 공통적으로 사용되는 사용 사례를 떼어 냄으로써 사용 사례 다이어그램의 복잡도를 줄일 수 있다. 이때 여러 개의 사용 사례와 떼어 낸사용 사례는 서로 포함관계에 있다고 말한다. [그림 5]에서 보듯이 사용 사례 다이어그램에서는 점선 화살표로 표시하고 <<include>>라는 표시를 한다. 포함된 사용 사례는 포함하는 사용 사례가 수행될 때 반드시 같이 수행되어야 한다. 그림의 사용 사례의 의미는 사용자가 정지 버튼을 누르거나, 로봇이 초음파 센서를 이용하여 장애물을 감지하였을 때는 액추에이터를 제어한다는 의미이다. 액추 에이터를 제어한다는 사용 사례에는 여러 가지 경우의 수에 따라 정지하는 기능, 왼쪽 또는 오른쪽으로 방향을 전환하는 기능, 후진을 하는 기능 등이 포함될 수 있다.

 

[그림 5] 포함 관계의 예

(다) 확장 관계
하나의 사용 사례는 특별한 조건 하에 다른 사용 사례로 확장될 수 있다. 포함 관계에 있는 2개의 사용 사례는 반드시 같이 수행되는 반면, 확장된 사용 사례는 예외적으로 이벤트가 추가될 때에만 수행된다. [그림 6]에서 보듯이 사용 사례 다이어그램에서는 방향이 반대인 점선 화살표로 표시하고 <<extend>>라는 표시를 한다. 이때 조건을 같이 명시하면 읽기 좋은 사용 사례 다이어그램이 된다. 장애물이 감지되어 액추에이터 제어를 할 경우에는 경로 계획을 수행하여 최적의 경로를 생성하게 된다. 만약, 감지된 장애물이 맵을 재생 성해야 할 만큼 중요한 장애물이라면 맵 빌딩을 수행하여야 한다. 아래 그림에서맵 빌딩은 조건이 성립되었을 때 수행하면 된다는 의미이다.

 

[그림 6] 확장 관계의 예

 

모델링 

 

• 객체 지향 프로그래밍(object-oriented programming)

 

객체 지향 개념에서는 소프트웨어를 여러 개의 객체 모임으로 생각하며 프로그래밍을 하는 방법이다. 여기에서 객체는 데이터와 관련 함수를 모아 놓은 것이다. 즉, 관련된 자료와 함수를 객체로 묶어 놓고 이들의 상호 작용에 의하여 작업이 수행된다. 객체 지향 개념은 다음 세 가지를 기본 요소로 한다.
(1) 객체(object)
객체는 우리 주변에 존재하거나 생각할 수 있는 것을 말한다. 예로 모바일 로봇에서 사람으로는 사용자 등이 있으며, 대상으로는 장애물, 작업물 등이 있으며, 장치로는 액추에이터, 센서, 로봇 팔 등이 있다.
(2) 클래스(class)
클래스는 비슷한 특성을 가진 객체들을 그룹화시킨 틀이며, 유사한 객체들의 집단에 대해 표현, 모델화, 추상화한 개념이다. 즉, 유사한 속성, 공통된 행위, 공통된 관계성, 공통된 의미를 가지는 객체들의 집단에 대한 표현 방법이다. 예로 모바일 로봇에서 사용자의 행동들, 센서의 결과값에 따른 액추에이터 등을 속성(데이터)과 행위(코드)로 추상화시켜 클래스로 만든다. 클래스는 객체 지향 소프트웨어 작성의 가장 기본적인 단위로서, 속성(또는 프로퍼티, attribute, property)과 메서드(또는 행위, method, behavior)로 구성된다.
(3) 메시지(message)
객체들은 각각 독립적으로 존재하지만, 다른 객체와 상호 작용하면서 소프트웨어를 운영한다. 이때 객체들 간에 상호 작용을 위한 수단이 메시지이다. 메시지는 어떤 한 객체가 다른 객체에게 특정 작업을 요청하는 신호이다.

 

• 통합 모델링 언어(UML, unified modeling language)

 

통합 모델링 언어, 즉 UML은 객체 관리 그룹(object management group)에서 관리하고 있는 소프트웨어 프로그램을 위해 사용되는 표준화된 범용 모델링 언어이다. UML은 BOOCH의 booch method, RUMBAUGH의 OMT(object modeling technique), JACOBSON의 OOSE(object-oriented software engineering)에 의해 소개된 모델 표기법을 단일화시킨 모델링 언어이다. 객체 관리 그룹은 1989년에 설립된 비영리 단체로서, 1997년 1월 IBM, HP, MICROSOFT, ORACLE 등 여러 업체들이 참여하여 UML 버전 1.0을 제출하였으며, 2003년 6월 실시간 시스템과 워크플로우 시스템을 모델링할 수 있는 버전 2.0이 발표되었다. UML은 객체 지향 설계를 위한 표준 언어로서, 소프트웨어 시스템의 산출물을 가시화, 명세화, 구축, 문서화하는 데 사용된다.
- UML은 소프트웨어 시스템을 시각적으로 표현하는 시각화 언어이다.
- UML은 소프트웨어 시스템의 구조를 명세화하는 명세화 언어이다.
- UML은 소프트웨어 시스템을 구축하는 데 사용되는 구축 언어이다.
- UML은 소프트웨어 시스템을 문서화하는 문서화 언어이다.

 

• UML 다이어그램의 종류

 

UML 다이어그램에는 [그림 7]과 같이 시스템의 정적인 부분(구조 모델링)을 가시화하기 위하여 클래스 다이어그램, 객체 다이어그램, 컴포넌트 다이어그램, 배치 다이어그램 등을 사용하며, 시스템의 동적인 부분(행위 모델링)을 가시화하기 위하여 사용 사례 다이어그 램, 순차 다이어그램, 통신 다이어그램, 상태 다이어그램, 활동 다이어그램 등을 사용한다.

 

(1) 클래스 다이어그램(class diagram)
클래스 다이어그램은 객체 지향 프로그램의 가장 근간이 되는 다이어그램으로 시스템의 정적인 구조를 나타낸다. 클래스 다이어그램은 시스템 내부에서 속성과 메서드들을 가진 클래스들과 그들 간의 관계를 표시한다. 두 클래스 간에 관계가 있다는 것은 이들이 하나 이상의 사용 사례(use case)를 수행하는 데 있어서 상호 협동하는 것을 의미한다.

 

[그림 7] UML 다이어그램의 종류

(2) 객체 다이어그램(object diagram)
객체 다이어그램은 객체와 객체들 사이의 관계를 나타낸다. 객체 다이어그램은 특성 시점의 객체들의 구조적 상태를 표현한다.
(3) 컴포넌트 다이어그램(component diagram)
컴포넌트 다이어그램은 컴포넌트 사이의 구성과 의존을 나타낸다. 컴포넌트 다이어그 램은 클래스 다이어그램과 관련이 있는데, 일반적으로 하나의 컴포넌트는 클래스 다이 어그램에 있는 하나 또는 그 이상의 클래스, 인터페이스, 통신들과 대응된다.
(4) 배치 다이어그램(deployment diagram)
배치 다이어그램은 시스템이 실행될 때 처리하는 노드와 그 노드에 있는 컴포넌트들의 구성을 나타낸다. 배치 다이어그램은 컴포넌트 다이어그램과 관련이 있는데, 일반 적으로 하나의 노드는 컴포넌트 다이어그램 안에 있는 하나 또는 그 이상의 컴포넌트를 수용하기 때문이다.

(5) 사용 사례 다이어그램(use case diagram)
사용 사례 다이어그램은 액터와 사용 사례를 이용하여 시스템의 기능을 나타내기 위하여 사용자의 요구를 추출하고 분석하는 데 사용된다. 사용 사례 다이어그램은 사용 사례와 액터(actor), 이들 간의 관계를 표현한다.
(6) 순차 다이어그램(sequence diagram)
순차 다이어그램은 클래스 상의 메시지 교환을 시간의 흐름에 따라 나타낸 다이어그 램이다. 순차 다이어그램은 객체들이 참여한 시간적, 순서적 처리 흐름을 동적으로 표현한다. 시간이 지남에 따라 객체 간에 어떤 상호 작용이 발생하였는지를 객체 간에 교환되는 메시지를 중심으로 표현한다.
(7) 상태 다이어그램(state diagram)
상태 다이어그램은 외부 자극에 대한 시스템의 동적 상태 변화를 나타낸다. 상태 다이어그램은 외부 이벤트에 대하여 민감하게 상태를 변화시키는 객체를 모델링한다. 상태 (state), 전이(transition), 사건(event)으로 구성되어 있으며, 사건에 따라 순차적으로 발생하는 객체의 행동에 중점을 둔다.

(8) 활동 다이어그램(activity diagram)
활동 다이어그램은 시스템 내부에 있는 활동의 흐름을 나타낸다. 활동 다이어그램은 유즈 케이스의 이벤트 흐름을 표현하는 데 적당하다.