I like the fact that you added an association between the file and the directory (although you did not specify multiplicity). Now as per your questions:
I wonder why the author did not use an Interface to represent the abstract type FileSystemElement? Isn't using an interface for this type correct?
You are correct, an interface could have been used. However, it is not the best choice. As you know, an Interface does not allow you to add implementation code to its methods. You better use a class instead of an interface because you can include implementation details of the methods you see common between the sub-classes. In this case, you may want to share the validation of the name property for example.
As we know, files and directories must have names with similar constraint (e.g. maximum length of 256 characters). Therefore, it would be nice if I model this in the FileSystemElement. But an interface cannot have a abstract attribute, so I have to repeat name attribute in both Directory and File classes. Is there any better workaround for this problem?
In c# you could define zero, one or more properties as part of an interface, for example:
public interface IFileSysElement { // Property declaration: string ElementName { get; set; } ... } So it is not a problem really.
The issue I see with the book's model is that having an association between a class and a sub class is cumbersome (to me). Another point to consider is the fact that the FileSystemElement name is the relative name (e.g. myFile.txt). You need another property or method to construct or retrieve the full file name for (e.g. C:\Temp\myFile.txt). This is the 'business identifier' for either classes.