1.유스케이스 다이어그램

1.1 유스케이스 모델의 이해

유스케이스 모델은 사용자와 시스템의 상호작용을 문서화하는 다이어그램과 텍스트의 집합이다. 그림 5-1은 유스케이스 다이어그램과 유스케이스 명세, 유스케이스 시나리오를 보여 준다.

유스케이스 모델은 시스템의 중요한 요소들에 초점을 맞춘다. 이 요소들은 사용자와 상호 작용해야 하는 시스템의 기능이나 특성을 뜻한다. 이렇게 시스템의 기능에 중점을 두는 모델링을 통해 다양한 요구를 수용할 수 있는 개념적인 틀을 만들 수 있다.

특성은 테스트, 모델링, 디자인, 구현될 수 있다. 어떤 특성을 요구한 의뢰인은 그 특성의 모델링 과정에서 협력자가 된다. 또한 특성에 초점을 두어 프로젝트의 범위를 정한다.

1.1.1 유스케이스 모델의 목적

유스케이스와 기능별 디자인의 중요한 차이점은 초점을 어디에 두는가에 있다. 기능별 디자인은 프로세스를 문서화한다. 그러나 유스케이스는 프로세스의 목표에 초점을 둔다.

목표 중심적 모델링은 목표에 이르는 수단이 아니라 도달해야 할 목표에 집중하게 한다.

1.1.2 유스케이스 모델의 자원

유스케이스 모델은 개별적인 요구 사항을 전체적으로 표현하는 서로 다른 세 가지 관점을 제공한다. 가장 기본적 자원은 유스케이스 다이어그램이다. 유스케이스 명세와 유스케이스 시나리오는 유스케이스 모델의 나머지 부분을 구성한다.

• 유스케이스 다이어그램
  유스케이스 다이어그램은 프로젝트에서 시스템, 액터, 유스케이스, 연관, 의존성을 나타내는 단순한 다섯 개의 도형으로 구성된다. 유스케이스 다이어그램의 궁극적 목표는 상위 수준에서 시스템과 외부 세계의 관계를 표현하는 것이다. 유스케이스 다이어그램은 매우 평면적이어서 시스템의 표면적인 모습만을 보여준다.

  예를 들면, ATM 어플리케이션을 나타낸 유스케이스 다이어그램은 ATM의 주 화면과 그곳에서 선택 가능한 메뉴를 기술할 것이다. ATM은 사용자에게 예금 지급, 입금, 잔액조회, 송금 등의 선택 사항을 제공한다. 각각의 선택 사항은 별도의 유스케이스로 표현할 수 있다. 사용자(시스템의 외부)는 사용하려고 하는 각각의 쓰임새(시스템의 내부)와 연결된다.
  

• 유스케이스 명세
  유스케이스 다이어그램에서 유스케이스는 '물품 접수'와 같은 표식이 붙은 타원으로 나타난다. 이런 표식은 시스템의 기능을 자세히 설명하지 못한다. 그래서 텍스트 형태의 유스케이스 명세를 사용한다. 유스케이스 명세는 시스템 기능의 분석과 설계 및 코딩에 필요한 기준이 되는 정보를 제공한다.

• 유스케이스 시나리오
  유스케이스 시나리오는 유스케이스에서 진행되는 하나의 논리적 흐름으로서 유스케이스 실행의 순차적 단계이다. 유스케이스가 포함할 수 있는 시나리오의 수에는 제한이 없다. 하나의 유스케이스에 대한 모든 시나리오 집합은 쓰임새가 실행될 때 발생할 수 있는 모든 상황을 포함한다.

  따라서, 시나리오 집합은 유스케이스 테스트 게획의 기초가 된다. 어플리케이션의 설계가 진행됨에 따라 유스케이스의 테스트 계획은 시나리오에 표현된 유스케이스의 목적에 맞게 확장된다.

1.1.3 유스케이스 다이어그램의 구성 요소 정의

유스케이스 모델을 구성하는 세 가지 자원 중 실제로 UML에 정의된 것은 유스케이스 다이어그램 뿐이다.

• 시스템: 시스템을 사용하는 액터(시스템의 외부)와 시스템이 제공해야 하는 특성(시스템의 내부)에 관련된 시스템의 경계를 정한다.
• 액터: 시스템 오퍼레이션의 수행과 관련된 사람, 시스템 또는 장치가 하는 역할이다.
• 유스케이스: 시스템의 주요 특성을 나타낸다. 이 기능이 없으면 시스템은 액터의 요구를 충족시킬 수 없다. 각각의 유스케이스는 반드시 구현해야 하는 시스템의 목표를 표현한다.
• 연관: 액터와 유스케이스 간의 상호 작용을 나타낸다. 각각의 연관은 유스케이스 명세에서 다이얼로그로 표현한다. 그리고 각각의 유스케이스 명세는 유스케이스의 분석, 디자인, 구현을 검증할 때 테스트 케이스가 되는 시나리오를 제공한다.
• 의존성: 두 유스케이스 간의 통신 관계를 나타낸다.
• 일반화: 어떤 유스케이스(또는 액터)와 이 유스케이스(또는 액터)로부터 특성값을 상속받아서 추가하거나 재정의한 유스케이스(또는 액터) 사이의 관계를 정의한다.

유스케이스 액터

시스템에는 항상 사용자가 있다. 유스케이스 다이어그램에서는 사람이나 시스템, 장치를 모두 액터라고 한다. 액터는 어떤 특정한 사람이나 시스템이 아니라 그 역할을 의미한다.

예를 들어, 액터는 재고 물품 목록을 작성하는 재고 관리 직원의 역할을 할 수 있다. 며칠 후에는 같은 직원이 트럭에서 물품을 하역하는 작업을 할 수도 있을 것이다. 이 경우는 동일한 사람이 두 가지 역할을 한다. 반대로 많은 사람이 같은 역할을 하기도 한다. 창고에 많은 관리 직원이 일하는 경우를 예로 들 수 있다.

액터는 시스템을 사용하는 방법에 대한 설명에서 주어 형태로 나타난다.

유스케이스

유스케이스는 시스템에게 요구되는 특성을 말한다. 이러한 특성이 없는 시스템은 만들 이유가 없다.

각각 의 유스케이스는 프로세스의 수행 목적을 나타내는 이름을 부여한다. 예를 들면 현금 입금, 예금 인출, 계좌 정리 등이다. 유스케이스는 자신이 지원하는 프로세스를 간접적으로 나타낸다. 그러나 유스케이스가 정말 강조하는 것은 프로세스 자체가 아니라 프로세스의 목적이다.

유스케이스에 대한 아주 일반적인 질문은 '어떤 요구사항을 유스케이스 다이어그램에 포함시키고 어떤 요구사항을 다른 곳에서 설명해야 하는가?'이다. 가장 간단한 답은 '액터가 직접 볼 수 있는 시스템의 특성만 유스케이스 다이어그램에서 모델링한다'이다. 예를 들어, 데이터를 DB에 저장한다고 하자. 그러나 이것은 액터가 실제로 볼 수 없는 작업이다. 액터가 볼 수 있는 것은 작업이 처리되었다는 메시지 뿐이다. 이러한 경우에 유스케이스 단계의 요구사항은 저장작업 자체가 아니라 그 작업의 성공이나 실패를 알려주는 메시지이다.

유스케이스 관계

지금까지 액터와 유스케이스에 대해 설명하였다. 이제 액터와 시스템의 특성을 연결시켜 보자.

• 연관 표기법
  그림 5-7과 같이 연관은 행위자와 유스케이스를 실선으로 연결하여 표시한다. 연관은 행위자와 유스케이스가 메시지를 교환한다는 것을 나타낸다. 중요한 것은 액터가 어떤 유스케이스를 사용해야 하는가를 분명히 하는 것이다. 이러한 연관은 시스템 인터페이스와 이후의 모델링 작업의 기초가 된다.
  

• 스테레오 타입 표기법
  스테레오 타입은 의존성, 클래스, 패키지, 분류자와 같은 UML 요소 전반에 걸쳐 사용된다. 표준 표기법은 $\ll \gg$로 나타낸다. 스테레오 타입은 별도의 수정 없이 UML을 확장할수 있도록 하는 도구이다. 스테레오 타입은 구현과 관련된 사항을 언급하지 않고 모델 요소의 역할에 추가적인 정보를 제공하며 모델 요소를 제한하는 역할을 한다.

• $\ll include\gg$ 의존성 표기법
  유스케이스는 다른 유스케이스의 도움을 받아야 하는 경우가 종종 있다. 예를 들면 '현금 입금'이나 '예금 인출'같은 유스케이스는 실제로 예금 계좌를 갱신하지 않는다. 대신 '계좌 갱신'과 같은 다른 유스케이스에게 작업을 위임하여 하나의 특성을 통해 모든 갱신 작업을 처리하도록 한다.

  그림 5-8에서 보듯 어떤 유스케이스가 다른 유스케이스에게 작업을 위임할 경우 "사용하는(작업을 위임하는)" 유스케이스에서 "사용되는(작업을 위임받는)" 유스케이스로 선으로 된 화살표 머리를 가진 점섬 화살표를 가지고 $\ll include\gg$라고 표기하여 의존성을 표시한다.

  이 때 '사용하는 (또는 호출하는)" 유스케이스의 실행은 "사용되는" 유스케이스의 기능을 포함하거나 통합함을 의미한다. $\ll include\gg$ 의존성이 서브루틴이나 함수와 비슷하다는 것을 눈치챘을 것이다.
  

• $\ll extend\gg$ 의존성 표기법
  $\ll extend\gg$의존성 스테레오타입은 어떤 유스케이스가 다른 유스케이스의 도움을 필요로 할 수 도 있다는 것이다. 이와 달리 $\ll include \gg$ 의존성 스테레오타입은 어떤 유스케이스가 다른 유스케이스를 항상 호출한다는 것을 의미한다. 유스케이스의 논리적 흐름 가운데 협력을 필요로 하는 곳을 확장 포인트라고 한다. 확장 포인트는 다른 유스케이스의 호출 여부를 결정하기 위해 조건을 검사하는 지점이다. $\ll include\gg$ 위존성에는 이런 조건을 검사하는 지점이 없다.

  $\ll include\gg$ 의존성과 $\ll extend\gg$ 의존성의 또 다른 차이점은 화살표의 방향이다. $\ll include\gg$ 의존성은 주체가 되는(현재 실행되고 있는) 유스케이스에서 도움을 받을 유스케이스를 가리킨다. 반대로 $\ll extend\gg$ 의존성은 확장 유스케이스(도움을 제공하는 유스케이스)에서 주체가 되는 유스케이스를 가리킨다.
  

• 일반화
  상속과 동일한 아이디어를 액터와 유스케이스에 적용하 것이 일반화이며 "~는 ~이다"관계라고 알려져 있다. 다음 문장을 보자. 선임 은행원은 추가적인 권한과 책임이 있는 은행원이다. 초과 인출 방지된 예금 인출 유스케이스는 요구 사항을 더 확장한 예금 인출 유스케이스이다.

  일반화를 모델링하기 위해 UML은 흰 삼각형 머리를 가진 실선 화살표를 사용한다.
  

1.2 유스케이스 다이어그램 만들기

1.2.1 사례 연구에 대한 유스케이스 다이어그램 만들기

다음 내용은 사례 연구를 가지고 설명하며 이것을 문제 기술이라고 하겠다. 문제 기술은 유스케이스 다이어그램을 만드는 데 필요한 기초 자료가 된다.

• 접수: 접수계 직원은 하역된 물품과 매입 지시서의 물품을 대조하여 입고될 물품을 인수한다. 직원은 매입 지시서의 물품이 도착했음을 회계부서에 알린다. 직원은 이러한 사실을 자동으로 알릴 수 있는 새로운 시스템을 원한다.
• 물품 적재: 물품은 주문이 취소된 것이거나, 반품된 것 또는 새로운 매입 주문일 수 있다. 미리 지정된 임시 보관 창고에 물품을 적재한다. 재고 관리 직원은 새로 들어온 물품을 제 위치에 쌓아 두고 물품 목록에 기록한다.
• 주문 처리: 다른 직원들은 주문받은 물품을 따로 분류한다. 출고된 물품은 재고 물품 목록에 반영한다. 그리고 주문 처리 부서에 주문받은 물품이 준비되었다고 알린다. 의뢰인은 주문 처리 완료 사실을 자동으로 통보해 주는 새로운 시스템을 원한다.
• 운송: 주문받은 물품의 준비가 끝나면, 물품을 포장하고 운송할 준비를 한다. 현장 작업자는 운송자에게 배달 지시서를 전달한다. 발송이 끝나면 물품 목록 상태를 수정하고 주문 처리 부서에 발송 완료 사실을 알린다. 의뢰인은 주문 처리 상태를 자동으로 통지할 수 있는 새로운 시스템을 필요로 한다.

단계 1: 목표 시스템 상황 설정

상황 설정은 항상 가장 먼저 해야 할 일이다. 상황 설정은 평가하고자 하는 정보에 대한 구조를 제공한다. 상황 설정은 비즈니스 안에서 시스템의 배치, 작업 프로세스를 포함한 비즈니스 계획, 목표, 다른 시스템, 사람들 그리고 그들의 업무, 정부나 계약과 같은 외부 개체에 부여되는 제약 사항 등을 정의한다.

문제 기술에 따라서 참가지는:

• ...을 지불 회계 부서에 알린다.
• ...을 주문 처리 부서에 알린다.
• ...하려고 운송자에게 ...을 전달한다.

상황 설정은 시스템의 보관 창고 오퍼레이션이 주문 처리 및 지불 회계 부서, 운송자와 유기적으로 연결될 수 있도록 만들어 준다.

단계2: 액터 확인

사람, 시스템 또는 시스템과 통신하는 장치들을 찾으라. 시스템 형태의 액터는 지불 회계와 주문 처리 시스템에 대한 통지와 같은 인터페이스, 외부 통신 장치 같은 것에서 가장 찾기 쉽다. 다른 액터는 재고 관리 시스템 기능의 참여자일 것이다. 이와 같은 모든 사용자는 시스템(즉, 유스케이스)이 요구하는 특성을 평가하고 발견하기 위한 기초 자료가 된다.

그림 6-1에서 문제 기술은 시스템 형태의 두 가지 액터를 보여준다.

• "직원은 매입 지시서의 물품이 도착했음을 지불 회계 부서에 알린다." 지불 회계 시스템은 입고 과정에 문제가 생겼을 때 이 사실을 알아야 하낟.
• "주문 처리 부서에 주문받은 물품이 준비되었다고 알린다." "발송이 끝나면 주문 처리 부서에 발송 완료 사실을 알린다." 주문 처리 부서는 주문 처리 상태를 고객에게 알려야 한다.
  
  그림 6-2에서 보듯이 문제 기술에서 네 종류의 사람 액터를 발견하게 된다.
• "접수계 직원은.. 입고될 물품을 인수한다." 물품을 입고하는 것은 사람이다. 이 역할을 접수라고 한다.
• "현장 작업자는 운송자에게...을 전달한다." 물품을 옮기는 사람, 운송자를 고용한 사람, 물품을 포장하는 사람, 목록을 작성하는 사람 등을 운송이라고 한다.
• "다른 직원들은 주문받은 물품을..." 주문받은 물품이 샘플이거나 고객의 주문이건 또는 도매이건 소매이건 간에 물품을 분류할 책임이 있는 사람을 주문 처리라고 한다.
• "재고 관리 직원은...을 기록한다." 물품 목록에 물품의 상태를 기록할 책임 있는 사람을 관리 직원이라 한다.
  

단계 3: 유스케이스 확인

단계 4: 액터와 유스케이스 사이의 연관 정의

단계 5: 액터와 유스케이스의 평가와 정제

단계 6: $\ll include\gg$ 의존성에 대한 유스케이스 평가

단계 7: $\ll extend\gg$ 의존성에 대한 유스케이스 평가

단계 8: 일반화를 위한 액터와 유스케이스 평가

2. 클래스 다이어그램

2.1

2.2 클래스 다이어그램: 연관

객체 사이의 연관(Association)은 사람 사이의 연관과 유사하다.

사람이 사람과 함께 일하려면 통신을 해야 한다. 그러려면, 전화번호나 이메일 주소와 같은 연락처가 있어야 한다. 게다가 어떤 통신 종류에 참여하거나 참여하지 않는 이유을 분명히 하기 위해 우리가 연관된 이유를 확인할 필요가 종종 있다. 예를 들면, A가 개발자이고 B가 DBA로서 관련되어 있다면, 둘은 마라 직원의 이익에 대한 내용을 업무 범위로서 토론하지는 않을 것이다.

둘의 상호 작용에는 몇 가지 제한 사항이 있을 것이다.

• 관계를 효율적으로 만들기 위해 참여자의 수를 제한하기를 원할 수 있다.
• 둘이 정당한 참여자라는 것을 보장하도록 참여자의 자격을 확인하기를 우원할 수 있다.
• 모두가 행동하는 방법을 알 수 있도록 참여자의 역할을 정의하길 원할 수 있다.

이와 같은 모든 요구사항은 객체에서도 동일하게 적용된다. UML은 이 모든 사항을 전달할 수 있게 하는 표기법을 제공한다.

2.2.1 기본적인 연관 표기법 모델링

다음의 표기법은 데어터베이스 모델링과 유사하다.

연관 이름

연관의 목적은 어떤 유형(클래스)의 객체가 다른 유형(클래스)의 객체에 어떻게 관련되어 있는지를 설명하는 동사 또는 동사구인 이름으로 표현할 수 있다. 예를 들어, 차를 가지고 있는 사람, 차를 운전하는 사람, 차를 빌리는 사람 등이다. 각각의 연관에서 참여자가 모두 같다고 하더라도, 각 연관의 목적은 유일하며 그렇기 때문에 서로 다른 규칙과 상호작용을 의미한다.

세 가지 예에 대한 UML 연관을 그리기 위해서는 네 가지의 기본적 요소로부터 시작해야 한다.

• 사람이나 차와 같이 참여하는 클래스.
• 두 클래스 사이에 연결된 선으로 표시되는 연관.
• 연관 선 위에 동사나 동사구로 표현되는 이름.
• 이름을 읽기 위한 방향.
  

연관 다중성

연관은 객체가 각각의 클래스와 연결되는 방법의 규칙을 정의한다. 그러면 얼마나 많은 객체가 관계에 참여하는지를 어떻게 정확히 설명하는가?

다중성은 참여하는 객체의 수를 정의하는 UML 용어이다. 연관에서 다중 값은 참여하는 각각의 클래스에 할당되어야 한다. 그림 10-2에서 설명하듯이 두 개의 질문을 하게 된다.

각 질문의 답은 질문과 관련된 객체 클래스 근처에 둔다. "얼마나 많은 사람들이..."에 대한 답은 사람 클래스 가까이에 있는 연관의 끝에, "얼마나 많은 차가..."에 대한 답은 차 클래스 근처에 있는 연관의 끝 부분에 놓는다.

다중성은 두 가지 방법으로 표현한다. 가장 보편적인 방법은 객체의 최대값과 최소값의 범위를 지정하는 것이다.

최소값..최대값

최소값과 최대값은 정수 값이어야 한다. 그러나 때로 상한 값을 모르거나 실제로 없을 수도 있다. UML에서는 상한 미정값의 표시로 를 사용한다. 는 최소값이 0이고 상한 값이 없는 경우나 0 또는 그 이상을 의미한다.

최소값과 최대값이 동일한 경우 표기법을 단순화할 수 있다. 4.4라고 쓰지 않고 4라고 쓰는 것이다.

다중성을 설명하기 위한 예제를 보자.

• 두 개의 점으로 나눠진 값은 범위를 의미한다. 1..3은 1과 3 사이를 의미한다. 5..10은 5와 10 사이를 의미한다.
• 쉼표로 나눠진 값은 가능한 값을 나열한 리스트이다. 예를 들면, 4,6,8은 연관에서 객체 4, 객체 6 또는 객체 8을 사용할 수 있다는 의미이다.
• *는 혼자 사용되면 0 또는 그 이상, 하한이나 상한이 없음을 의미한다.
• 1..* 범위 내에서 *가 사용되면 상한이 없음을 의미한다.

연관의 역할

가끔씩 연관 이름을 결정하기 어려울 때가 있다. UML에서는 이름 대신 사용하거나 가능한 한 분명하게 연관된 이유를 설명할 수 있는 대안을 제공한다. 연관에서 객체가 어떻게 참여하는지를 설명하므로 이것을 역할이라고 부른다.

예를 들면, 많은 직원들은 프로젝트에 기여한다. 그러나 그들은 여러 가지 다른 방법으로 참여하고 있다. 그림 10-3은여러 개의 연관을 어떻게 그릴 수 있는지 그리고 참여하는 유형을 구별하기 위해 어떻게 라벨을 붙일 수 있는지를 보여준다. 각각의 역할은 역할을 수행하는 객체의 유형 근처, 연관의 끝 부분에 놓는다. 그것을 연관의 한쪽 끝에만 사용하거나 둘 다 또는 전혀 사용하지 않을 수 있다.

연관 제약 사항

연관 제약 사항은 연관의 끝에 {}를 사용하여 추가한다.

2.2.2 확장된 연관 표기법 모델링

연관 클래스

연관 클래스는 연관에 대한 정보를 캡슐화한다.

그림 10-6에서 고객은 제품을 주문한다. 그러나 고객이 제품을 주문할 때, "그들이 얼마나 많이 주문했는가?", "그들이 언제 주문했는가?", "세일 기간은 언제까지인가?" 등과 같이 일반적으로 알아야 할 것들이 더 있다.

이러한 모든 질문의 답은 단순히 데이터이다. OOP에서 모든 데이터는 객체 내에 포함되어야 한다. 클래스는 각각의 객체 유형을 정리해야 한다. 그래스 클래스 내부에 이 모든 데이터를 정의한다. 연관을 설명하는 데이터를 보여주기 위해 새로운 연관 클래스를 점선으로 연관에 연결한다.

재귀 연관

재귀 연관은 객체가 자기 자신을 연결된 것이다. 연관의 양쪽 끝이 같은 클래스를 가리키는 것을 제외하면 지금까지의 연관 표기법과 정확히 같다.

그림 10-7의 두 예제는 같은 표현이다. 유일한 차이는 한 쪽은 역할을 사용했고 다른 쪽은 연관 이름을 사용한 것 뿐이다.

2.3 클래스 다이어그램: 집합 연관

2.3.1 집합 연관과 복합 연관 모델링

그림 11-1은 연관, 집합 연관(Aggregation), 복합 연관(Composition) 사이의 관계를 간략히 보여준다.

• 모든 집합 연관은 연관의 한 종류이다. 그러므로 모든 집합 연관은 연관 관계의 모든 특성을 포함하며 자신만의 특성을 가질 수 있다.
• 모든 복합 연관은 집합 연관의 한 종류이다. 그러므로 모든 복합 연관은 집합 연관의 모든 특성을 포함하여 자신만의 특성을 포함할 수 있다.
  

집합 연관의 요소

집합 연관은 연관의 특별한 형태로서 집합에 속하는 객체들이 단순히 서로를 알기만 하는 독립적인 객체가 아님을 의미한다. 대신 조금 더 복잡한 객체를 만들기 위해 객체들을 조립하거나 어떤 형태로 재조립하게 된다. 예를 들면, 자동차를 만들기 위해서는 수많은 부품들을 조립한다. 또는 물리적으로 연결되어 있지 않지만 하나의 개체처럼 움직이는 팀과 같이 논리적인 집합체를 생각할 수 있다.

클래스 다이어그램에서 집합 연관을 모델링하기 위해서는:

• 멤버 클래스와 집합 클래스 사이에 연관을 표시하는 실선을 그린다.
• 집합 클래스 쪽의 연관 끝에 마름모를 그린다.
• 연관의 양쪽 끝에 알맞은 다중성을 표기한다. 또한 관계에 대한 규칙을 정의하는 데 필요한 제약 사항이 있으면 기술한다.
  

복합 연관

복합 연관은 멤버의 존속 기간이 집합체의 존속 기간에 달려 있는 집합 연관이다. 집합체는 멤버의 생성과 소멸을 제어한다. 멤버 객체는 집합을 떠나서는 존재할 수 없다. 집합 연관의 견고한 형태인 복합 연관은 검은색 마름모를 사용하여 표기한다.

그림 11-3의 팀 예제는 흰색 마름모로 표현되는 집합 연관이다. 선수들은 모여서 팀을 이룬다. 그러나 선수들은 팀이 해체되더라도 활동을 계속 할 수 있다. 이와는 달리, 책 예제는 검은색 마름모로 표기하는 복합 연관이다. 책은 장으로 구성된다. 장은 책에서 분리되면 아무런 의미가 없다. 책이 존재하지 않으면 장도 존재하지 않는다.