협력 다이어그램이란 ?

객체 사이의 연관관계 뿐만 아니라, 각 객체들이 주고 받는 메시지들을 공간에 따라 배열한 것. 객체 다이어그램의 확장으로 볼 수 있다. 


◎시퀀스 다이어그램과의 유사점 및 차이점

유사점: 시퀀스 다이어그램처럼 객체들 사이의 교류를 보여준다. → 따라서, 시퀀스와 협력다이어그램의 상호 변환이 쉽다.

차이점: 

- 시퀀스 다이어그램: 객체간의 교류를 시간의 순서에 초점을 두어 표현

- 협력 다이어그램 : 공간에 따라 배열시킴, 교류를 수행하는 객체들의 전체적인 조직과 상황(Context)에 초점을 맞춤


◎표현

- 두 객체 사이를 연관선으로 연결. 연관선 위에 메시지가 전달되는 객체 쪽으로 화살표 방향을 가진 선을 긋는다. 메시지의 의미는 "메시지를 받는 객체로 하여금 어떤 오퍼레이션을 실행하라" 라는 의미. 메시지 끝에 '( )' 을 붙임으로써 매개변수를 넣을 수 있도록 한다.


예제) 아래 그림

1. GUI는 키 입력은 운영체제에게 알린다. 

2. 운영체제는 CPU에게 그 사실을 알린다. 

3. 운영체제는 GUI를 갱신한다. 

4. CPU는 비디오 카드에게 GUI갱신에 필요한 명령을 내린다. 

5. 비디오 카드는 모니터로 메시지를 전송한다. 

6. 모니터는 화면에 문자를 표시하고, 사용자에게 피드백을 제공한다.

+ State Diagram 상태변화 추가


표현 

객체의 사각형 안에 객체의 상태를 나타낸다. 변경된 상태의 객체를 나타내는 사각형에다가 쇄선을 그리고 스테레오타입 <<become>>을 붙인다. 


◎"음료수 사기" 쓰임새를 시퀀스 다이어그램으로 표현

1. 소비자가 자판기의 프론트 앞에 서서 투입구에 돈을 넣는다. (insert)

2. 소비자가 마실 음료수를 고른다. (Select)

3. 돈이 금전등록기에 들어간다. (Send)

4. 등록기는 선택된 음료가 디스펜서에 들어있는지를 체크한다. 

5. 간단한 시나리오이기 때무에, 선택된 소다가 준비되어 있고, 등록기는 현금잔고를 갱신한다. 

6. 등록기는 디스펜서를 사용하여 소다를 자동 판매기의 프론트로 보낸다.


◎"음료수 사기" 에서 "액수가 맞지 않는경우"

1. 사용자가 음료수 가격보다 많은 돈을 투입한 경우

2. 음료수 자판기가 충분한 거스름돈을 가진 경우

3. 음료수 자판기가 충분한 거스름돈을 가지지 않은 경우


* 각 단계의 소수점 숫자의 표현은 동일한 단계에서 여러시나리오가 중첩됨을 나타냄

◎ "음료수사기" 시나리오에서 "음료수 자판기가 충분한 거스름 돈을 가지고 있지 않을 때"


1. 거스름 돈이 없음을 알리는 메시지를 출력한다. 

2. 투입된 돈을 돌려준다.

3. 맞는 돈을 넣을 것을 지시한다. 

4. 이때, 사실상 사용자와 자판기와의 거래(Transaction) 는 끝이 난다.

◎While문을 표현 : * [조건]


메시지를 받는 객체 사각형을 사선방향으로 쌓는다.

객체로 전송되는 메시지에는 ' * ' 가 붙은 대괄호 조건문을 붙여준다. 만약, 메시지 전송순서가 필요하다면, 조건문에 1.... n 처럼 순서를 표시할 수있다. 


Ex) 은행원이 여러창구에 늘어선 고객들을 순서대로 맞아 서비스를 하려고 할때.

◎ 동기화

다른 메시지들과 자신의 메시지를 동기화 하는것. 즉, 다른 메시지들이 전송이 이루어진 후에야 자신의 메시지를 전송하는 상황을 의미함.


◎표현 

메시지가 전송되기 전에 완성되어야 할 메시지 리스트를 ' ; '로 구분하여 나열하고 ' / ' 로 리스트의 끝임을 알린다.


◎ 판촉 캠페인 

1. 수석 마케팅 부회장은 판촉 VP에게 특정 제품의 캠페인을 만들것을 요구한다.

2. 판촉 VP는 캠페인을 만들고 이것을 판촉 관리자에게 할당한다.

3. 판촉 관리자는 판매원에게 이 캠페인에 따라 제품을 팔 것을 요구한다.

4. 판매원은 고객들에게 제품을 사줄 것을 부탁한다.

5. 판촉 VP가 할당을 내리고 판촉 관리자가 지시를 마친후에, 회사 홍보 담당 전문가가 지역 신문에 자신들의 캠페인을 광고로 실어줄 것을 요청한다.




◎ 활동 다이어 그램이란?


처리단계(Activity), 결정(Decision), 분기처리(Branch)를 표현하는데 있어서, 업무과정이나 Operation 에서 처리되는 일들을 효과적으로 나타내는데 유용하게 사용된다.


활동 다이어그램은 Flow Chart와 상당히 흡사하다. State Diagram의 확장으로 볼 수 있다. 해당 활동 내의 처리가 끝나면 그 다음의 활동으로 자동적으로 옮겨진다. 

◎ 신호

 

활동이 진행되는 도중에 신호(Signal)을 보낼 수도 있다. 신호가 보내어지면 그 신호를 받은 쪽은 활동을 개시해야 한다.


◎ 동시경로

◎ 짜장면 집에서 주문을 하는 과정 


1. 손님이 메뉴에서 음식을 고른다.

2. 웨이터를 부르고, 주문한다.

3. 웨이터는 주방장에게 주문사항을 알린다.

4. 만약 주문한 음식의 재료가 떨어졌으면 주방장은 웨이터에게 알린다. 

5. 웨이터는 손님에게 알린다.

6. 다시 1번 부터 반복한다.



◎ 활동 다이어그램에 역할 (Role)을 표시함으로써 처리 과정에 속해있는 각 활동의 책임이 누구에게 있는지 나타낼 수 있다. 


쓰임새 (USE CASE) 란 ?

시스템의 사용에 대한 시나리오의 집합


목적

- 사용자의 관점에서 시스템을 모델링하기 위함. 즉, 사용자가 시스템에 대하여 바라는 바를 표현함으로써 사용자의 시점을 빨리 이해하고 쓸모있고 (Useful), 쓸 수 있는 (Useable) 시스템을 만들 수 있도록 함.


사용 

- 대게 의뢰인과 개발팀이 참조하는 설계문서의 한 부분으로 사용.

- 새로 만들어진 시스템을 테스트하는데 사용 : 사용자의 시스템 사용 시나리오를 표현한 것이기 때문에 테스트도 그 시나리오에 따라서 하면 됨


시스템 분석가와 사용자 힘을 합쳐 시스템의 사용 방법을 결정하는데 도움이 된다. 시스템이 가진 User Interface 설계 & 프로그래밍 방식에 매우 도움이 되는 다이어그램

[요구사항 수집]의 "시스템 요구사항 파악"의 과정과 [분석]과정에서의 출력물 → 사용자와의 대화를 통하여 얻어낸 정보를 표현한다. 



▶ USE CASE 의 분석과정 및 사용 방법 : 사용자를 만나 의견을 듣는것으로 시작 

1. 시스템 사용자를 시스템 분석과 설계의 초기 단계에 참여시킴

2. [요구사항 수집] 의뢰인과 대화 → 초기 클래스 다이어그램 → 사용하고 있는 용어를 통해서 개념정리 → 사용자 와의 대화가 유연해짐 

3. 사용자와 대화 → 설계하고자 하는 시스템을 가지고 어떤 일을 하는지 질문 → 얻어낸 대답은 미래에 USE CASE 다이어그램을 만드는대 토대로 사용

4. USE CASE 에 대한 간단한 설명을 붙임 → 설명이 많을 수록 사용자와 할 수 있는 대화의 밀도도 높아진다. 


USE CASE 의 재사용을 위한 방법 : 

- 포함(inclusion) : 다른 쓰임새를 구성하는 하나의 진행 과정으로 쓰임새를 사용.

- 확장(extension) : 기존의 쓰임새에 몇 개의 단계를 추가하여 새로운 쓰임새를 만듦.


※ USE CASE 만들때 주의사항

 - 해당 시나리오를 시작할때 만족 되어야 하는 선행조건

 - 시나리오가 완료될 때 만족되어야 하는 종료조건




행위자 (Actor)

시스템과 교류하는 사람이나 시스템 또는 장치, UseCase를 시작시키고, 구성하는 진행단계가 끝나면 그 결과를 받는다. 막대기로 사람모양을 표현, 행위자의 이름은 막대인간 아래에 쓴다. 


쓰임새 (UseCase) 

타원으로 표현, 쓰임새의 이름은 타원 안쪽 또는 아래에 쓴다. 쓰임새를 시작시킨 행위자는 왼쪽, 결과를 받는 행위자는 오른쪽에 표현. 행위자와 쓰임새 간의 연결은 실 선으로 그림. 


시스템 

쓰임새를 둘러싸는 사각형으로 표현, 행위자는 대게 시스템 외부에 있는 반면, 쓰임새는 시스템 내부에 존재한다. 즉, 쓰임새분석을 통하여 시스템과 외부세계와의 경계를 효과적으로 보여줄 수 있다.



[시나리오의 진행단계 나타내기]


- 쓰임새는 시나리오로 진행되며, 각 시나리오는 진행단계로 이루어진다. 

- USECASE를 구성하는 시나리오는 각각의 USECASE 다이어그램의 페이지에다가 텍스트로 적어둔다. 

- USECASE 다이어그램에  Note를 붙임으로써 표현할 수 있지만, 너무 지저분하게 보인다면 다이어그램의 생명인 '명확성'을 잃어버릴수 있다. 


 작성요령

1. USECASE를 시작하는 ACTOR

2. USECASE가 시작하는데 필요한 선행조건

3. 시나리오의 진행단계

4. 쓰임새가 끝나는데 필요한 종료조건

5. 쓰임새의 결과를 받는 행위자

6. 쓰임새의 가정 - Ex) "한번에 소비자 한명이 음료수 자판기를 사용한다" 등..

7. 간단한 한 문장 정도의 설명문


포함(Include) - 쓰임새가 다른 쓰임새를 포함하는 관계

 여러 쓰임새에서 공통으로 중복되는 시나리오가 있다면 이 시나리오를 따로 분리하여 새로운 쓰임새로 만들고 , 새로 만든 쓰임새를 각 쓰임새 마다 포함시키면 됨. 사용하려는 쓰임새가 사용되어지는 쓰임새를 필수적으로 포함해야 한다. 


포함된 쓰임새는 절대로 단독으로 존재할 수 없으며, 전체 쓰임새의 부분으로만 존재한다. 


표현

- 포함관계에 있는 쓰임새 사이를 쇄선으로 잇고, 포함되어지는 쓰임새 쪽에 화살표 머리를 둔다.

연결선 위에는 스테레오 타입 <<include>>를 붙인다. 


Ex) 자판기 내용물 공급자와 수금원이 포함된 자판기 시스템의 USECASE 다이어그램

→ "내용물 보충하기" 쓰임새와 "수금하기" 쓰임새 시나리오에서 공통으로 중복된 보안장치 해제나 보안장치 관련 설정과 관련된 진행 단계들을 따로 떼어내서 새로운 쓰임새로 만들고 포함시켰다. 



확장(Extend) - 쓰임새와 그 쓰임새를 확장한 확장 쓰임새의 관계

쓰임새의 시나리오에서, 어떤 조건에 따라 특정한 진행 단계의 행위를 확장하고자 다른 쓰임새를 참조하는 것을 말함. 이 때 확장 용도로 사용하기 위하여 참조되는 쓰임새를 '확장 쓰임새' 라고 함. 이 확장 쓰임새를 참조하는 쓰임새를 기본(Base) 쓰임새라 한다. 확장 쓰임새를 참조하는 시나리오의 특정한 진행단계를 확장포인트(extend point)라 한다. 즉, 특별한 조건에서만 수행되는 부 흐름부를 모형화 한 것으로, 어떤 조건이 부합되어야만 포함되는 쓰임새를 표현한다. 


따라서, 포함 관계의 쓰임새와 달리 확장 쓰임새와의 관계는 선택적이다. 

※ 기본 쓰임새에서 특정한 시나리오의 진행 단계의 확장이기 때문에 확장된 쓰임새는 절대로 단독으로 존재할 수가 없다.


표현   

두 쓰임새 사이를 쇄선으로 잇고, 기본 쓰임새 쪽에다가 화살표 머리를 둔다. 연결선 위에는 스테레오 타입 <<extend>> 를 붙입니다. 


예) 음료 자판기의 "내용물 보충하기" 쓰임새에서 각 음료수 마다 판매실적이 엇 비슷할 때는 문제가 없지만, 만약 음료수 마다 판매실적이 두드러지게 차이가 난다면, 우리는 판매실적이 따라 채우는 음료수의 양을 달리해야 할 것이다. 즉, 특정한 조건(판매실적 차이가 클 때) 이 만족 되었을 때 판매실적에 따라 달리 보충하도록 기존의 "내용물 보충하기" 쓰임새를 확장한 "판매실적에 따라 보충하기"라는 새로운 쓰임새를 만들고 확장관계를 가지게 했다. 


일반화 (Generalization) 


- 쓰임새를 상속하는 것을 의미 

- 상속을 해주는 쓰임새를 "부모 쓰임새"라 하고, 상속을 받는 쪽을 "자식 쓰임새"라고 한다. 

- 자식 쓰임새는 부모 쓰임새의 모든 행동과 의미를 물려 받으며, 여기에 자신만의 행동을 추가 할 수 있다. 

- 부모 쓰임새가 등장하는 곳에 자식 쓰임새를 대신 놓을 수 있다. 

- 두 쓰임새 사이를 실 선으로 연결하고, 부모 쓰임새 쪽에 속이 빈 화살표 머리를 붙인다. 

- 일반화 관계는 행위자(Actor)사이에도 적용할 수 있다. 

- 예) "음료수 사기" 쓰임새에서 상속받은 "음료수 자~알 사기" 쓰임새가 있다. 이 자식 쓰임새에는 "음료수 사기" 쓰임새의 모든 행동과 의미를 사지고 있고 추가적으로 '얼음추가', '여러 음료수 혼합하기' 등의 행동을 갖을 수 있다. 


예) 음료를 보충하는 '공급자'가 있고 수금을 하는 '수금원'이 있다. 그러나, 이 두 행위자 모두 음료수 제공 업체 직원으로 볼 수 있다. 


그룹화

관련된 쓰임새를 하나의 패키지로 그룹화 하는것. 시스템이 여러개의 서브 시스템으로 구성되어 있거나, 시스템에 대한 다양한 요구를 수집하기 위하여 사용자의 의견을 조사할 때 (즉, 요구사항이 각각의 쓰임새로 표현되기 때문에) 그룹화를 한다. 패키지 다이어그램에서 패키지 안에 관련되 쓰임새를 넣어서 표현


예) 가계부 시스템에서 통장 관리 관련된 쓰임새를 패키지로 그룹화 한것


[요구사항 수집]과 [분석] 영역에서의 USECASE 다이어그램


1. 의뢰인과의 인터뷰

2. 시스템 분야 (문제해결 대상이 되는 Domain)에 대한 기초가 되는 Class Diagram을 그림

3. 용어 정리후 사용자와의 인터뷰

4. 행위자의 추상적 수준의 USECASE 다이어그램을 그림으로써 기능적인 요구사항 정리

5. 사용자와의 계속적인 인터뷰를 통한 시스템 요구사항 구체화 → USECASE 모델은 상세한 자신의 시나리오를 가지게 되고, 포함관계 & 확장관계가 나타나게 됨.


* 그 분야에 대한 이해가 부족하게 되면 쓰임새가 쓸데없이 많아지게 되고 시스템 설계와 개발 작업에 오히려 발목을 잡히게 됨