무언가를 이해하지 못하면 쉽게 해산 할 수 있습니다. UML은 구조화 된 방식으로 아이디어를 전달하는 데 사용되는 엔지니어링 도구입니다. 게임은 다른 것과 마찬가지로 엔지니어링 될 수있는 시스템입니다. 어쨌든 게임의 복잡성과 역동 성은 게임의 일부와 상호 작용을 시각적으로 표현하여 귀중한 가치를 만듭니다.

UML 다이어그램은 논의중인 시스템 모델의 다른보기입니다. 내 프로그램 앞에 앉아 시작하는 사람에 대한 사용 사례로 시작합니다. 게임의 경우 두 종류의 사용자가 있습니다 : 디자이너와 플레이어. 나는 그들이 볼 수있는 각각의 일에 유스 케이스를 씁니다. 그런 다음 어떤 서비스를 제공해야하는지 파악하기 위해 CRC 카드를 만듭니다. 그런 다음 이러한 서비스와 해당 관계를 제공 할 인터페이스에 대한 클래스 다이어그램을 작성합니다. 이것은 CRC 카드를 기반으로합니다. 다음은 계획 및 오케스트레이션이 필요한 초기화와 같은 이벤트에 대한 동적 다이어그램입니다. 그런 다음 인터페이스를 구현하는 클래스를 보여주는 더 자세한 정적 다이어그램.

나는 게임의 요구 사항을 충족시킬 수 있도록 서비스를 제공하는 방향으로 코드를 작성하고 프로토 타이핑하고 발전시키고 있습니다. 사용 사례를 통해 사용자를 지원하지 않는 빌드 된 것은 없습니다. 쓸모없는 다이어그램 요소를 작성하지만 인터페이스 코딩과 다이어그램 사이에 쓸모없는 코드는 거의 작성하지 않습니다. 다이어그램 작성은 제가 작성하는 수업이 전체 시스템에 적합한 방식을 이해하고 있다는 확신을줍니다.

내가하려고하는 요점은 사소한 프로그램을 계획없이 작성할 수 있지만 게임은 사소한 것입니다. 얼마 전, OOP가 처음 등장했을 때 많은 실험이 있었고 몇 가지 모범 사례가 앞당겨졌습니다. 소프트웨어 개발 커뮤니티는 소프트웨어 디자인에 대해 쓰고 분석 할 언어가 필요하다는 데 동의했습니다. UML은 우리가 개발 한 언어입니다. 우리는 모두 그것을 알고 이해하므로 문제에 대한 다른 사람들의 솔루션 (도서, 온라인 토론, 기사, 패턴 카탈로그 등)을 사용하고 표준 표기법을 읽는 법을 배워야하지 않는 경우. 보너스로, 다른 언어로 된 시스템에 대해 스스로 생각하게되면 예기치 않은 것을 배우게됩니다.

여러 가지 방법론이 존재하지만 모두 문제를 식별하고 하나의 솔루션을 체계적으로 설명합니다. 이것은 공학입니다. UML은 거대하고 복잡하지만 모든 모델을 사용하는 모델은 없습니다. 스위스 군용 칼과 같습니다. 이를 알고 엔지니어링 프로세스를 지원하기 위해이를 사용하는 방법을 찾아야합니다. 중요한 것은 어떤 프로세스 나 방법론이 아니라 당신이 가지고있는 것입니다. 그렇지 않으면 복잡해집니다.

답변