[개발 설계] 유연한 설계를 위한 유스케이스와 콘웨이 법칙

이번 우아한 테크코스 프리코스의 3주차 미션을 설계하기 위해 많은 준비를 했는데요, 이번 읽고있는 책인 ‘클린 아키텍처’에서 ‘유스 케이스’라는 개념을 알게 되었습니다. 그리고 ‘유스케이스 다이어그램’ 이라는 것을 같이 알게 되었고, 이를 이용한 시스템 설계를 소개해드리고자 합니다.

❓유스 케이스란 (Use Case)

유스 케이스(Use Case)의 정의는 다음과 같습니다.

‘소프트웨어 개발에서 사용자가 시스템과 상호작용하는 방식을 기술하는 기능적 요구사항을 표현하는 기법’

이를 이용하여 비지니스의 요구사항을 분석하고, 시각화 할 수 있다고 합니다.

유스 케이스는 다음을 포함하고 있습니다.

1. 액터(Actors): 시스템과 상호작용하는 주체. 주로 사용자, 시스템, 외부 기관 등을 나타냅니다.
2. 액션(Action): 액터와 시스템 간에 수행되는 특정한 작업 또는 상호작용을 의미합니다.
3. 목표(Goal): 유스케이스가 완료될 때 얻어야 하는 목표를 나타냅니다.
4. 전제조건(Precondition): 유스케이스가 시작되기 전에 충족되어야 하는 조건들을 명시합니다.
5. 후속조건(Postcondition): 유스케이스 완료 후 시스템의 어떤 상태가 되어야 하는지를 기술합니다.

이러한 사항을 포함하고 있는 추상적 개념이라는 것입니다!

 

❓유스 케이스 다이어그램?

유스 케이스 다이어그램은 예시를 보면 훨씬 명확하게 다가올 텐데요. 제가 만든 유스케이스 다이어그램을 보여드리겠습니다.

이번 우테코 프리코스의 미션을 유스 케이스 다이어그램으로 만들어 보았습니다.

제가 느낀 장점이라면 ‘의존성’을 한 눈에 볼 수 있다는 것입니다! 요구 사항을 한번에 이해하고, 의사소통이 어떤식으로 이루어지는지를 알 수 있다는 것은, 유지 보수에도 엄청난 장점이라는 것이겠죠?

 

저는 이번 유스케이스 다이어그램을 만들면서, 들었는 의문이 하나 있었습니다. ‘이렇게 객체를 분리를 하는 기준이 뭐지?’ 라는 것이었습니다. 그리고 저는 객체 지향의 본질적인 의미에서 답을 찾을 수 있었습니다.

‘객체 지향이란 실제 세계를 모델링 함으로써 소프트웨어를 조금 더 쉽게 이해할 수 있는 패러다임’

이는 콘웨이 법칙이라는 것에서 살펴볼 수 있었습니다.

 

❓콘웨이 법칙 (Conway's Law)

콘웨이 법칙(Conway's Law)은 소프트웨어 개발에서 조직 구조와 그 조직이 생성하는 소프트웨어 시스템의 디자인 간의 상호작용에 관한 법칙이다.

조직의 의사소통 구조와 동일한 설계를 하라는 것입니다. 만약 UI 디자인 팀이 따로 있는 곳이라면, UI를 담당하는 시스템과 로직을 담당하는 시스템을 분리할 필요가 있다는 것이죠.

저는 여기서 드는 의문은 ‘UI팀이 없더라도 UI를 담당하는 시스템을 분리하는 것이 좋지 않나?’ 라는 것이었습니다. ‘클린 아키텍처’에서는 이렇게 말합니다.

‘좋은 아키텍트는 결정되지 않은 사항의 수를 최대화 한다’

UI팀이 없고, 시스템을 분리해야할 필요성을 느끼지 못했음에도 UI 시스템을 분리하는 것은, 결정되지 않은 사항의 수를 최소화 하는 행위라고 생각했습니다. 그 이상의 설계는 불필요하고, 유연성을 없애는, 오히려 나쁜 행위라 생각할 수 있겠네요. 이는 추측성 일반화라는 말과 일맥상통하는 부분이라고 생각합니다.

결국 적절한 분리라는 것은, 요구 사항에 있다는 것이었죠.

❗결론!

이번 시간에는 조금 추상적인 설계에 대한 내용을 이야기 해봤습니다. 결국 좋은 설계라는 것은 “요구 사항”을 충족하는 것이고, 요구사항에 맞게 객체를 분리해 나갈 수 있다는 것!