UML Class diagram - does multiplicity dictates implementation restriction?

Consider simple aggregration with my favourite example (chess): I would create chessboard like 2D array of chessmen (at least it seems to me to be good solution) e.g:

chessman [,] board=new chessman[8,8];

This means that on each position there can be a chessman. But in reality, there will be only 32 chessmen at most. And that is the problem - what should class diagram display, implementation or my assumption?

BOARD<>----Chessman 0..64 or 0..32?

Because the implementation definitely allows 64, while game logic should not allow more than 32.

No it should as 0...64, because there are 64 ChessMan, where only 32 of the array is not null.
in class-diagram we do not omit(decrease) the references which are null.

Once again, this is true that there will be only 32 object not null, but this is not a class-diagram thing, you NEED whole 64 blocks in the game, and this is the class-diagram describes.
But beside it, I really don't see your approach is very well designed, because there are always +50% of the board array is null. so my suggestion is just keeping(tracking) the ChessMans, and find each ChessMan location with itself. you also may need to remove the lost ChessMans.

as you see in the above example too, this is possible that for losing each ChessMan, causes setting a null value in the array, but in class-diagram we always set the ACTUAL size of associations.

There is a big difference with your and mine solutions, your solution is optimized for best process execution(optimized for speed), in case that for each move you just read the related block from the board and process the of the word.
but mine is optimized for best memory management(optimized for memory usage), in this solution you need just check whole of the array to find out who is belong to related block.

and the another solution would be keep tracking the locations