Use Case Realization
Design 단계에서는 use case diagram그리는 것과 Step By Step Description을 만드는 작업까지 했다.
그러나 Use Case 만으로는 코드 만드는것을 할 수는 없다.
코드를 위한 최종 목표는 Class Diagram이며, 그 중에서 제일 중요한 것은 Public Function들이 정의되는 것이다.
이는 Communication Diagram을 통해 만들어지는 Design Class Diagram이 만들어지면 해결이 된다.
그런데 Use Case Diagram에서 바로 Class Diagram으로 바로 넘어갈 수 없다.
Communication Diagram을 거쳐야 Class Diagram을 만들 수 있다.
커뮤니케이션 다이어그램까지만 만들면 툴을 통해 디자인이 다 나오게 된다.
아래의 과정이 전체 과정이다. ▼
이 전체 과정을 하나 하나 확인해보자.
1번, 2번 과정 : Use Case Diagram
Use Case Diagram & Collaboration
Actor와 Use Case로 표현하는 것은 그동안 많이 봤을 것이다. ▼
위와 같은 방식으로 Use Case Diagram을 그리는 것에는 익숙할텐데, 그동안 보지 못한 새로운 표기 방식이 등장한다.
Use Case 중에도 점선으로 된 애들을 Collaboration이라고 한다. ▼
Collaboration은 단어의 뜻대로 객체들의 협력을 의미하며, 협력 객체는 Use Case를 실현시켜준다.
이를 «realize» 라는 stereotype을 통해 묘사한다.
위의 Collaboration을 조금 더 자세히 묘사하면 아래와 같이 묘사할 수 있다. ▼
객체와 링크들로 이루어져있는 형태로 그려진다.
이 링크들은 message passing을 의미하며, 이는 각 클래스들은 message passing을 하는 객체들의 참조(reference)를 알고 있어야 한다.
그러므로 반대로 이야기 하면, 객체에 참조가 있다면 위와 같이 링크(선)로 묘사한다.
그런데 이와 같이 묘사를 하기 위해서는 클래스의 Stereotype에 대해서 알고 있어야 한다.
Class Stereotypes
Class Stereotypes은 3가지 종류 중 하나로 지정할 수 있다.
Stereotype의 뜻 그대로 하나를 지정하면 지정된 하나의 역할만 수행한다.
Boundary Class
외부랑 상호작용을 담당하는 클래스를 말한다.
Actor들과 상호작용하는 클래스가 Boundary 클래스이다. ▼
Boundary 클래스는 클래스 내부에서 처리된 것들을 actor들에게 보여주고 상호작용한다.
즉, input과 output만 관리하며 Actor들과 상호작용만 한다.
Entity Class
우리가 일반적으로 아는 객체가 Entity 클래스에 해당한다.
특정 정보를 관리하고 서비스를 제공한다. ▼
학생 정보를 저장하는 Student Class, 교수 정보를 저장하는 Professor Class 등등이 해당한다.
Entity 클래스는 자신에 대한 정보만 관리하며 다른 클래스의 정보에 대해서는 관리하지 않는다.
Control class
그런데 Boundary와 Entity만으로는 전체 Use Case를 알 수 없다.
자기가 어떤 input을 받고, 어떤 output을 내보낼지, 관리할 특정 정보가 무엇인지, 어떤 정보를 특정 정보라고 칭하는지 아는 클래스가 없다는 것이다. ▼
그래서 이를 조정하는 coordinator가 필요하고, 이를 맡고 있는게 Control class이다. ▼
Control 클래스는 쉽게 말하면 다른 클래스들에 대한 시나리오를 전부 알고 있는 클래스이다.
Boundary와 Entity 모두 이 클래스가 시키는 대로만 하면 된다.
Message labels in communication diagram
Communication Diagram 내부에는 소통을 보여주는 Message Label들이 있는데, 이는 아래와 같이 기술할 수 있다.
| Type of message | Syntax example |
| Simple message. | 4 : addNewAdvert() |
| Nested call with return value. The return value is placed in the variable name. |
3.1.2 : name = getName() |
| Conditional message. This message is only sent if the condition [balance > 0] is true. |
5 [balance > 0] : debit (amount) |
| iteration. | 4.1 *[For all adverts] : getCost() |
숫자는 순서를 말하며, 숫자 뒤에 점(.)으로 들어가는 것은 nested 된 것들을 말한다.
함수는 뒤에 ()를 붙이는 것으로 표현하며, [] 안에 들어간 것은 조건으로 branch를 의미한다.
*는 모두라는 의미로 4.1번과 같이 *[For all adverts]라고 하면 모든 adverts에 대해 반복한다는 의미이다.
"그러면 이런 메세지 라벨들은 무엇을 보고 만들까?"
Step by step description
우선 step by step description을 작성하는 것에서 시작한다.
아래와 같이 작성된 step by step description을 토대로 위의 Message label들을 만든다. ▼
| Action action | System response |
| 1. Displays the list of all clients. | |
| 2. Selects the relevant client. | |
| 3. Displays the list of all campaigns belonging to the client. | |
| 4. Selects the relevant campaign. | |
| 5. Displays the list of all adverts belonging to the campaign. | |
| 6. Create a new advert after filling up necessary data fields. | |
| 7. Present a message confirming that the advert has been created. |
이렇게 Step by step description을 작성하면서 필요한 Entity들을 찾아내고 정의한다.
‘어떤 Entity가 어떻게 동작할거다’ 라는 것을 가정하며, 이 가정한 내용들이 class diagram이 된다.
3번 과정: Communication Diagram
역할 분담
위에서 작성한 내용들을 토대로 Communication Diagram을 만든다.
우선 Boundary와 Control 클래스는 무조건 하나씩, 한 쌍으로 존재하기 때문에 둘을 미리 정의를 하고 Entity 클래스를 찾으면 된다.
Communication Diagram을 작성할 때 중요한 것은 외부에 보여주기 위해 내부에서 작업하는 객체들의 역할을 얼마나 효율적으로 배치하는 것이다.
"그렇다면 역할 분담은 어떻게 이루어질까?"
객체들의 역할 분담은 객체들의 Operation을 정의하는 것으로 이루어진다.
그런 관점에서 Communication Diagram을 만들어야 한다.
이름 정의
Message labels에 있는 내용들을 클래스로 만들고 옮겨야하는데, 이때 클래스 이름은 Use case의 내용을 축약한 형태로 정한다.
위의 예시를 그대로 따오면, addNewAdvert라는 Use Case는 AddAdvert라는 이름이 된다.
그리고 이를 Actor에게 보여주는 Boundary class의 경우엔 뒤에 UI를 붙이는 식으로 클래스 이름을 정한다.
예시를 이어서 사용하면 AddAdvertUI가 된다.
Nested number의 의미
예시 그림을 보면 3.1과 3.1.1, 3.1.2가 있는 것을 볼 수 있다.
이렇게 nested 된 번호들은 함수가 앞의 번호 내부에서 실행이 된다는 의미이다.
예를 들면, 3.1은 3번 함수에서 실행이 되는 것이고, 3.1.1은 3.1번 함수의 내부에서 실행이 되는 것이다.
그림으로 표현하면 아래와 같다. ▼
그런 식으로 클래스를 다 정의했다면, 이제 위의 Message label들을 붙여주면 된다.
내용을 채우면 아래와 같다. ▼
여기까지 작성이 끝났다면 필요한 Public function들이 정의가 된 것이다.
만약에 추가로 Public function이 더 필요하다면, 그림을 잘못 그린 것이다.
여기에 작성된 Public function 그 외의 public function은 작성이 되면 안된다.
4번 과정: Analysis Class Diagram
특정 Use Case의 Class Diagram만을 그린 것을 Use Case Class Diagram이라고 한다.▼
한 Use Case에 대해서 Class Diagram을 그리고 나면, 여러가지 Class들과 function들이 나오게 된다.
그런데 다른 Use Case에서도 Class Diagram을 그리면 중복되는 Class들과 function들이 나올 수 있다.
모든 Use Case에 대해서 Class Diagram을 그리고 이를 합쳐 중복되는 Class와 function들을 합치면 Analysis Class Diagram이 만들어진다. ▼
전체 흐름도
마치며
이번 글에서는 Use Case Realization의 전체 과정을 봤다.
3번과 4번 과정의 내용이 워낙 방대해서 이번 글에서는 다 보지 못했지만, 다음 글에 하나씩 자세히 볼 예정이다.
'CS > 소프트웨어 공학' 카테고리의 다른 글
| 15. Detailed Design (0) | 2024.02.03 |
|---|---|
| 14. Sequence Diagram (작성중) (0) | 2024.02.03 |
| 12. Configuration and Version Management (0) | 2024.01.31 |
| 11. 다형성(Polymorphism) 예제 (0) | 2024.01.31 |
| 10. 객체 지향 프로그래밍 (Object-Orientation Programming) (0) | 2024.01.31 |
