Chess MVC UML diagram for Java chess game

Question

I have a school project of creating a game with Java, I chose to program chess. My teacher want us first to design the game by creating a UML design of all classes we think will be necessary for the game.

The problem is the wants it to be design with the MVC pattern, Model View Controller. I tried to design the UML

Here my diagram:

I'm also using observer pattern in order to communicate between the different parts.

I would really appreciate it if someone can help me and tell me how can I improve this diagram so it follows the mvc pattern. I tried handing my teacher diffrent UML designs but he is still not pleased

Here is an updated link to the uml diagram: click me

Answer 1

Not knowing exactly the criticism of your teachers, I'll go through your diagram and highlight the main points of concerns.

UML semantics and syntax

Player does probably not inherit from the GameModel contrary to what is documented in the diagram. Consider removing the hollow arrow head, and make the relation a simple association.

You can remove all the white diamonds of shared aggregation: the UML specification does not define any semantic for it, and it de facto means the same as when using simple associations. Always prefer simplicity ;-)

The class syntax should be respected, with a compartment for the class name, a compartment for attributes and a compartment for operations. The <> and enum stereotypes should be above the name of the type.

On using patterns

Unfortunately, you diagram does not show how the Observer pattern allows to decouple the related classes. You should define the Observer and the Subject interface outside the MVC, and show with interface realization, which class implements the observer but also which one implements the subject.

This being said, in MVC, the View is in general an observer of the Model. It is not very common to make the controller an observer of the Model, unless you want to have some state dependent menus where some options are greyed depending on the state of the model).

On the MVC

There are many variants of the MVC and many confusions with similar patterns. Hence, I'll refer to the original MVC definition:

• Model is everything about game logic, including a move, because moving pieces is part of the game model.

• Controler is everything related to processing user input. So processing mouse or keyboard events does belong there. Auxiliary function to transform the user input into commands/requests to the model and meaningful arguments to provide to the Model should also belong to the controller. But the commands themselves (e.g. move pieces in the game) should belong to Model classes. Because it's the model that knows the rules of the game, and if the model doesn't keep track of the move, the game's state wiuld be inacurate.

• View is everything about rendering the model in a certain way for the user.

Special topics

The human player and the AI player are both special kinds of players. The player state (color, whose turn it is, time spent on a move, ...) belongs to the model. The human player input of the user is in most of the case about commands (moves) performed by the one of the two player in the Model.

Th AI should be part of the model, since it changes the state of the game on its own and doesn't fit on its own to view or controller.