Intro
프로젝트 일정 수립
실제 게임 개발에서 복잡한 업무들에 맞춰 일정을 산정하듯, 간단한 프로젝트를 진행할 때에도 기획, 구조 설계, 기능 구현, 테스트 및 버그 픽스, 제출(발표 자료)로 단계를 나누어 시간을 분배해야할 필요가 있다. 이때 구조 설계 과정에서 활용되는 것이 통합 모델링 언어(UML)이다.
프로그램 구조 설계
구현해야 할 기능과 요구 조건을 명확히 인지(설계)하고 프로그램의 구조를 구현하는 경우와 그렇지 아닌 경우는 극명한 차이를 갖는다. 따라서 게임의 구조 설계 단계는 오히려 기능 구현보다 더 중요한 과정이라고 볼 수 있고, 우리는 게임 내에 객체는 어떤 것이 있는지, 객체들은 어떤 방식으로 통신하며 상호작용하는지, 객체 지향 원칙을 제대로 지켰는지 구조화시켜 알아볼 필요가 있다.
UML
하지만 게임 개발에는 다양한 이해관계자가 참여하는 것이 보통이기에, 만약 나만의 방식으로 구조화를 하면 다른 사람들이 이를 보고 한 번에 이해하기에 어려움이 따를 것이다. 따라서 의사소통을 용이하기 위해 우리는 구조화 단계에 공통된 언어를 사용할 필요가 있고 이를 UML이라고 부른다.
Class Diagram
UML에는 굉장히 많은 종류가 존재하지만, 이 중 게임 개발에서 많이 활용되는 것은 클래스 다이어그램이다. 거의 모든 객체지향 메서드를 대표하는 모델링 기법으로 볼 수 있으며, 객체 유형과 객체 간의 다양한 종류의 관계를 표현할 수 있다.
위처럼 클래스의 필드와 메서드를 나타낼 수 있고, 클래스와의 관계도 표현하는 것이 가능하다.
class
공통
접근 한정자 - public : + , private : - , protected : #
기타 속성 - readonly : {readonly} , static : 밑줄
길러멧
인터페이스나 추상 클래스와 같은 요소를 표시하기 위해 사용되는 《 》기호를 뜻한다. 보통 인터페이스, enum, 추상 클래스 등에 사용되지만 확장 클래스에도 사용하는 등 쓰임이 다양하다.
Relationship
이미지 참고 : https://en.wikipedia.org/wiki/Class_diagram
Association - A has B
다른 클래스의 인스턴스에 대한 참조를 가지고 있을 때 가지는 연관 관계이다.
A → B 처럼 방향이 있는 실선은 A가 B를 참조한다는 뜻이다.
A - B 처럼 방향이 없는 실선은 서로 참조하는 경우, 참조가 아닌 경우이다.
Inheritance - A is B
부모 클래스와 자식 클래스 간의 상속 관계를 나타낼 때 사용한다.
Realization - A can B
인터페이스나 추상 클래스 등 상속한 자식 클래스에서 실제 기능을 구현할 때 사용한다.
Dependency - A use B
Association과 마찬가지로 클래스 간 참조관계를 나타낼 때 쓰이지만, 차이점은 Association은 변수로 다른 클래스와 참조가 있는 경우에 사용하고, Dependency는 메서드의 매개변수나 반환에 사용되는 등의 참조 관계가 있는 경우 사용한다.
Aggregation
전체 - 부분 집합 관계이지만 서로 Life Cycle을 공유하지 않는 경우에 사용한다.
Composition
전체 - 부분 집합 관계이며, 서로 Life Cycle을 공유할 때 사용하여 Aggregation보다 강한 집합을 의미한다.
user와 grade를 예로 들자면 User가 전체, Grade가 부분이 되며, User 객체가 소멸되면 Grade 객체도 소멸하고 User가 복제되면 Grade도 복제되어야한다.
또한 Grade의 인스턴스의 경우 User를 복제할 때 얕은 복사가 일어나지 않도록 Clone을 구현해야 비로소 Composition 관계라고 할 수 있는 것이다.
