The diagrams created by ERtool use graphical hints to suggest cardinality constraints, subtyping and identification functions. The conventions used are, unfortunately, mostly idiosyncratic. After a careful examination of the existing notations, major theoretical or practical flaws where discovered. In some cases, the notation would have worked just for binary relationship types. In other cases, it was utterly counterintuitive.
Thus, ERtool uses its own notation, which is directly derived from Chen's, but also borrows from the standard mathematical notation, Object Role Modelling, and a bit of fantasy.
Entity types are represented by boxes containing the type label. No attributes are shown, as they are hyperlinked, and can thus be easily accessed. The border of abstract types is dashed.
Subtyping is represented by a dashed arrow from an entity type to its direct supertype(s).
Weak entities are marked by a double frame, as in standard entity-relationship diagram practise. Identification functions are simply represented by a bold arrow from the weak entity type to the owner (the name is not relevant, as there can be at most one such function between two entity types)
Relationship types are represented by diamonds containing the type label (again, no attributes are shown). Relationship types that are to be instantiated to multirelations are shown with a thicker border (as multirelations are somehow fatter than relations).
The representation of the remaining cardinality constraints is very simple: a cardinality constraint of the form (1:x) adds a black dot at the end of the corresponding leg. Thus, when you see a black dot you should read "mandatory" (as in Object Role Modelling). A cardinality constraint of the form (x:1), instead, generates an arrow tip near the diamond. This corresponds to the mathematical fact (explained in detail in the Section called Cardinality Constraints in the Chapter called Overall System Design) that such a constraints makes a leg into a partial function from the entity set to the relationship set. Moreover, it shows immediately and intuitively that there is just one way to go from the entity set to the relationship set (and thus to the other component type sets, as legs are functions).