객체지향 설계, UML 다이어그램 - 콘솔 체스 구현하기 (Java)

이번 포스팅의 주제는 콘솔 체스 구현하기입니다. 복잡한 체스 룰을 조금 간략화시켰고, UI부분은 콘솔 출력으로 대체했습니다. 들어가기 앞서서, 설계의 중요성은 말 안해도 누구나 다 아실겁니다. 저도 마찬가지로 일단 돌아가게만 구현을 했다가 리팩토링 과정에서 한줄한줄 찾아가면서 코드를 고치면서 생산성이 많이 떨어진다는 느낌을 받았던 경험이 있는데요, 그래서 저도 이번에는 설계를 가능한 범위까지하고, 구현을 하면서 설계를 보완해나간다는 목표를 잡았습니다. 설계를 잘 할 수 있도록 도와주는 툴이 있는데요, 테스트 코드 작성과 UML 모델링 언어입니다. 흔히 TDD라고도 말하는, 테스트 주도 개발 방법론입니다. 테스트 코드 작성을 선행으로 전체적인 그림을 그린 후에 구현하는 방법인데, 이 방법은 사실 저도 실천해본적이 없습니다. 이번에는 UML 통합 모델링 언어로 설계에 도움을 받았습니다. UML 통합 모델링 언어는 설계를 시각화하는 방법 중 하나입니다.

UML 통합 모델링 언어

UML(Unified Modeling Language)은 산출물의 명세화, 시각화, 문서화할 때 사용하는 모델링 언어로 시스템을 표현하기 위한 표준적인 방법을 제공합니다. 설계를 대략적으로 시각화함으로써 클래스와 클래스 간의 관계, 사용자 관점에서 시스템의 표현 등을 눈에 쉽게 들어오게 그릴 수 있습니다. 객체와 객체가 이루는 관계가 복잡한 만큼 여러 종류의 다이어그램으로 표현할 수 있습니다. 종류는 아래와 같습니다.

 

구조 다이어그램

• Class diagram

아래처럼, 클래스 속성, 함수, 변수 타입들로 구성된 다이어그램으로 클래스와 클래스 간 관계를 나타냅니다. 저도 이번 포스팅에서는 클래스 다이어그램을 통해서 시각화하였습니다.

• Object diagram

클래스 다이어그램과는 달리, 클래스 인스턴스, 값이 매겨진 행동을 가지고 있는 독립된 객체정보를 표현하는 다이어그램입니다.

• Package Diagram

모델 요소들을 그룹화한 다이어그램으로, 아래처럼 패키지 간의 관계로 표현합니다.

 

행위 다이어그램

• Use Case Diagram

사용자 관점에서 바라본 시스템을 표현한 다이어그램입니다.

• Activity Diagram

여러 활동들이 순차, 병행 방식 등을 수행하는 상황을 표현하는 다이어그램, 시스템 전체의 흐름을 표현

• State Diagram

하나의 객체가 다른 객체와 상호작용에 따라 어떻게 변화하는지 표현, 하나의 객체의 활동변화를 묘사하는 방법입니다. 다른 다이어그램과 달리 하나의 객체의 상태 변화와 상호작용에 초점을 맞춘다는 특징이 있습니다.

• Sequence Diagram

여러 대상 간의 상호작용을 시간 순서에 따라 표현하는 방법입니다.

 

• Communication Diagram

동작에 참여하는 객체들 간 메시지를 표현, 관계까지 표현하는 방법입니다. 저는 이 방법이 가장 객체 지향적으로 시각화할 수 있는 방법이라 생각해 클래스 다이어그램과 커뮤니케이션 다이어그램으로 시각화를 하였습니다.

 

구현

구현 결과

아래와 같이 체스의 프로토 타입을 구현했습니다. 실제 체스와는 다르게 간략화된 룰을 적용했습니다.

(프로그램 실행)
체스 보드를 초기화했습니다.
ABCDEFGH
1♜♞♝.♛♝♞♜
2♟♟♟♟♟♟♟♟
3........
4........
5........
6........
7♙♙♙♙♙♙♙♙
8♖♘♗.♕♗♘♖
ABCDEFGH

명령을 입력하세요> ?A2
A3
명령을 입력하세요> A2->A3
--- 점수 현황표 ---
흑팀 : 39 | 백팀 : 39

ABCDEFGH
1♜♞♝.♛♝♞♜
2.♟♟♟♟♟♟♟
3♟.......
4........
5........
6........
7♙♙♙♙♙♙♙♙
8♖♘♗.♕♗♘♖
ABCDEFGH

명령을 입력하세요> B7->B6
--- 점수 현황표 ---
흑팀 : 39 | 백팀 : 39

ABCDEFGH
1♜♞♝.♛♝♞♜
2.♟♟♟♟♟♟♟
3♟.......
4........
5........
6.♙......
7♙.♙♙♙♙♙♙
8♖♘♗.♕♗♘♖
ABCDEFGH

명령을 입력하세요>

이번 포스팅에서 코드를 올리지는 않겠습니다. 구현을 할 때 최대한 역할을 분리하되 비슷한 책임은 한 객체가 맡을 수 있도록 응집성을 높였습니다. 그리고 비슷한 객체의 생성의 역할 -> Piece Factory 객체로 응집, 출력은 OutputView, 입력은 InputView를 만들었고, 다이어그램에는 없지만 예외처리 메시지는 Errors enum을 생성했으며 사용자가 입력 가능한 Menu 객체를 생성해서 입력의 정규표현식과 관련 로직을 묶어주었습니다. 도메인 영역은 비즈니스 로직만 처리할 수 있도록 분리했습니다. 아쉬운 점은, 반복되는 로직들이 많았는데 메서드를 잘 재사용하지 못한 것 같고 새로운 메서드를 만들어서 처리된 부분이 많습니다. 다음 번에는 재사용성이 높게 하위 기능 단위로 잘 분리한 후, 필요한 메서드들로 상위 기능을 잘 구현하도록 구현해야겠다고 느꼈습니다.

 

그리고 구현을 완료한 후, 클래스 다이어그램을 그렸습니다. UML 다이어그램을 사용하는 것이 아직 익숙하지 않아 머리 속에 설계를 생각만해보고 구현을 했는데, 설계를 다이어그램으로 그려보는 것이(혹은 종이에라도) 도움이 될 것 같습니다. 확실히 객체 간의 관계나 로직의 흐름이 한 눈에 보여서 좋다는 생각이 듭니다. 

콘솔 체스 클래스 다이어그램

 

클래스 다이어그램 대신 아래의 커뮤니케이션 다이어그램으로 그려보았습니다. 클래스의 자세한 상태와 행위를 알 수 있는 클래스 다이어그램과는 달리, 객체와 객체 간의 협력을 중점으로 이해할 수 있습니다. 각각의 상태는 생략되고 객체 간의 메시지만 나타내기 때문에 전체적인 프로그램의 유기적인 흐름을 잘 파악할 수 있다는 장점이 있습니다. 프로젝트의 특징에 따라 적절한 UML 다이어그램으로 시각화한다면 복잡한 프로그램도 단순하게 나타낼 수 있을 것 같습니다.

커뮤니케이션 다이어그램