[협업]개발 학생의 협업 도전기 #2-3.객체지향 개발 방법론(OOAD) : Stage 2030 Analysis

Stage 2030 Analysis에서는 크게 두 가지 To-Do가 있다.

하나는 외부 Actor가 시스템에 접근하기 위해 필요한 Interface 역할을 하는 Operation들을 시스템 수준에서 분석하고 찾아내는 것이고, 다른 하나는 개발에 참여하는 개발자들이 전체적인 시스템 도메인에 대해 파악하기 위한 시간을 가지는 것이다.

본격적인 시스템 해부 및 설계의 단계로 넘어가기 위한 중간 단계로써, 이 단계를 거치면서 개발의 방향성이 더욱 구체화된다.

INDEX

1. Use-Case Model
   1. Use Case
   2. System Operation
2. Domain Model
3. Traceability Analysis

---

1. Use-Case Model

Use-Case Model은 사용자가 시스템에게 기대하는 행동을 Operation으로 변환한 결과물 set이라고 할 수 있다.

결과물 set에는 Casual Format으로 표현된 Use Case와, 해당 Use Case를 통해 그린 System Sequence Diagram, System Operation이 있겠다.

    1. Use Case(Activity 2031. Define Essential Use Cases)

Activity 2031. Define Essential Use Cases에서는 Stage 1000에서 정의된 Brief Format의 Use Case를 refine하여 Casual Format으로 확장한다. Casual Format으로 표현된 Use Case "Buy Items"는 아래와 같다.

Casual format of Use Case "Buy Items"

여기서 눈여겨 보아야 할 부분은 Typical Courses of Events인데, 해당 칼럼에서 Actor와 System이 상호 작용하는 모습을 순서대로 나타내고 이것을 바탕으로 시스템을 더 깊게 분석하기 때문이다.

우리 팀의 Brief, Casual Format Use Case 각각을 아래에서 비교해볼 수 있다.

Brief, Casual Format of '1. 모드 변경하기'

Brief, Casual Format of '2. 모드 활성화'

왼쪽의 Brief Format에 비해, 오른쪽의 Casual Format Use Case가 더 시스템의 동작을 상세하게 기술하고 있음을 알 수 있다.

    2. System Operation(Activity 2032. Refine Use Case Diagrams, Activity 2033. Define System Sequence Diagrams)

위 과정에서 도출된 Casual Format Use case를 바탕으로 아래와 같은 System Sequene Diagrams를 그린다.

System Sequence Diagram

위는 Use Case "Buy Items"에 대한 System Sequence Diagram이다. 왼쪽의 텍스트로 작성된 Casual Format Use Case를 오른쪽 그림으로 도식화하여 나타낸다.

그림을 보면 텍스트로 나열되어 있던 정보들이 시스템에 요청하는 몇 가지 Operation들로 변환되었는데, 이것을 System Operation이라고 부르며, System Operation은 외부 Actor가 시스템에 접근하는 인터페이스로써의 역할을 한다.

 

우리 팀의 Use Case를 System Sequence Diagram으로 표현한 모습은 아래와 같다.

Actor가 System에 요청하는 메시지는 오른쪽 화살표로, System이 Actor의 요청에 응답하는 메시지는 왼쪽 화살표로 표현된다.

01

System Sequence Diagram

그중 Actor가 System에 요청하는 메시지들만 추출해내면 그것이 System Operation이다.

System Operation은 외부 Actor가 System을 사용하는 인터페이스의 역할을 하므로, 이후 설계 단계에서 이 System Operation을 구체화한다.

2. Domain Model

Domain Model

Domain Model은 시스템을 구성하기 위한 요소들을 간략한 수준으로 파악해봄으로써, 개발자들의 시스템에 대한 이해를 돕는다.

주로 어떠한 개체들이 시스템에 있어야 하는지, 개체들은 어떠한 특성을 갖고 있는지, 또 그들 간의 관계는 어떠한지 등등이 있겠다.

Domain Model을 작성했을 때의 장점은, 개발자들이 저마다 그리는 시스템의 구현 방식을 어느 정도 통일해주고, 시스템에 대한 분석 단계를 마치고 설계 단계로 조금 더 부드럽게 넘어갈 수 있다는 점이 있겠다.

또한 개발자들이 충분하게 Domain에 대한 파악을 하는 경우 Domain Model을 그대로 확장하여 Class Diagram으로 사용할 수도 있다.

 

아래는 우리팀이 작성한 Domain Model이다.

 

Domain Model

3. Traceability Analysis

해당 포스팅은 OOPT(Object-Oriented process with Traceability)를 기반으로 진행하는 수업을 따르는데,

여기서 Traceability(추적성)란 앞으로 계속해서 시스템을 분석하고 설계하는 과정을 진행하면서 확장되는 use case와 그것을 통해 추출되는 결과물들(System Operation, Operation, ...)을 지속적으로 연결하여 하나의 Test에서 실패가 발생했을 때 그 원인을 빠르게 찾아내어 거슬러 올라갈 수 있도록 하는 성질이다.

아래 그림을 보면 조금 더 이해가 용이하다.

Traceability Analysis

Analysis Stage에서는 System Sequence Diagram까지 찾아내었으므로 이전의 Stage 1000에서 찾아낸 System Function(Functional Requirements)과 Use Case, System Sequence Diagram들을 연결한 상태이다.

앞으로의 Stage를 거치면서 Traceability Analysis Table은 계속해서 확장되고, 딱히 코드를 보지 않더라도 Traceability만 따라가다 보면 어디서 문제가 발생하는지 파악할 수 있는 단계가 될 것이다.

 

우리 팀의 Traceability Analysis Table은 아래의 번호 Mapping의 형태로 기술하였다.

Traceability Analysis

---

Stage 2030을 지나면서 Stage 1000 Planning에서보다 확실히 문서가 코드에 가까워졌음을 느낄 수 있다.

텍스트로만 서술되어 있던 Use Case를 통해 System Sequence Diagrams를 그리고, 그것을 통해 System Operation을 뽑아 외부 Actor가 System에 접근할 수 있는 System Interface들을 뽑아놓은 것이 현재 상태이다.

이렇게 추려낸 Interface들을 Stage 2040 Design 단계에서 구체화함으로써 더욱 코드와의 거리를 좁혀갈 것이며, 이러한 단계를 계속 거치면서 생산되는 문서들은 바로 개발에 착수할 수 있는 상태가 될 것이다.