这张图是一个很好的开始，但还有很多工作要做。我会提醒你注意一些你需要改进的地方，但这并不妨碍你在实践中学习。
首先是一些手续：

• 使用关系箭头仅指示可导航性。如果链接是双向的，则使用2个箭头或不使用。例如，我们可以理解View知道ChessBoard，但不清楚ChessBoard是否知道Views：然后ChessBoard如何通知Views在移动完成后板的状态已经改变？
• 表示multiplicity：例如，我想知道是一个ChessBoard对应一个View，还是会有多个Views对应同一个Chessboard？
• 避免关联和属性之间的歧义。例如，在View中，有一个类型为ChessBoard的model属性。但您也与ChessBoard有关联。那么这都是相同的ChessBoard吗？或者我们有两个ChessBoard，一个关联，一个嵌入？从属性中删除model，并在关联的末尾指示model作为关联对象的名称，这样会更清楚。
• 从Controller开始的关联突然分成两个是不太实际的，特别是如果你告诉我们关联结束和多重性。我更喜欢在视觉上有两条截然不同的线。

现在进入核心：

• 你的模型不应该只是一个ChessBoard。模型应该是一个Game，它有几个元素。ChessBoard只是其中之一：Piece s的当前位置。那么layers呢？他们在哪里？我怎么知道是两个人总管怎么知道轮到我们了
• 如果调用ChessBoard而不是棋盘，可能会造成混淆。例如，仅凭棋子的位置信息，棋盘能否确定isGameOver()？有没有可能一个玩家决定放弃？因此，请尝试根据类实际表示的内容来命名它们。
• 我怎样才能知道哪些Pieces在电路板上的位置？
• 如何知道Piece的color？
• 我如何知道董事会的单元格是空闲的还是被占用的？
• 如果一个棋子因为被拿走而被从棋盘上移除，会发生什么？

您的UML图必须发展以阐明所有这些。因此，我认为要完成ChessBoard和Piece，您至少缺少Game，Player，BoardCell（也称为“Square”），也许每个玩家的Pieces的一些容器仍然在棋盘上。
一旦你完成了，你还需要考虑模型，视图和控制器之间的关系，以确保控制器知道足够给予命令给模型，而且模型可以通知视图，当有什么变化。

• P.S：我已经添加了一些链接到一个Chess Programming Wiki，因为这个网站描述了一些基本的概念编程的游戏，一些usual questions以及大量的参考.但是请注意，尽管这个资源信息量很大，但它并不是面向对象的。