Representing Design Aspects

What are some important aspects of design, and how can they be represented in design and implementation languages? Help me out here ...

Modularity: Graphical notations such as UML work well for expressing object/class-level modularity. Package-level modularity is also addressed fairly well.
: Object-oriented languages can express object/class modularity well, but a good IDE or hierarchy browser is needed for anything very large.
Object interaction: Graphical notations such as UML can express static object interactions fairly well, dynamic interactions less well. Programming languages show dynamic interactions well (read the method), but static relationships less well. Careful naming of instance variables can help with static relationships.
: CRC communicates object interaction in a very unique way: people pick up the cards and move them around while telling stories about what the objects are doing. This can build understanding, even among very disparate observers, very quickly.

The same dynamic can be used with other object stand-ins; one I've used is to use partial OMT object diagrams in the same way as cards. People can also act out roles of objects notated variously e.g. on whiteboards without physically picking up the 'objects'. --JimPerry

Method signatures: RonJeffries is not aware of any design notation addressing method signatures with types. Please help. UML represents method names as an annotation on lines connecting objects, and provides for a list of methods supported in object/class definition diagrams.

OMT allows the method list in object diagrams to specify signatures; UML object diagrams follow OMT in many ways but I haven't verified this case --JimPerry.
Interface specifications (IDL, C/C++ headers, Eiffel, Ada, Java, etc.) provide a context to specify method signatures, sometimes including contractual conditions. Comments can annotate interface behavior beyond the specific language capability (and if the interface is the specification for implementation, they "should be" authoritative). --JP

Behavior: In RonJeffries' opinion, no design notation expresses behavior as clearly as (practically any) implementation language. For some very simple expressions of behavior, very high level languages such as Prolog or awk or SNOBOL can be useful, but they do not in general scale up to the application level.

Event trace/Timing diagrams can be used to document scenarios captured using CRC-flavor acting. --JP
Again, some languages allow expressing precondition/postcondition contracts in interfaces. Any given implementation may not document the intended use of different subclassing, which may not exist yet (YAGNI), but is often covered in the designers' mental model. --JP

Type: Expressing of type information is problematical in all the design notations I know. Type doesn't exactly leap out at you in any of the graphical notations, since everything looks like a box or cloud. A hierarchy diagram helps ... maybe.
: Some forms of type information is fairly well represented using a hierarchy of names: Employee, RetiredEmployee?, DeadEmployee?, SickEmployee? ...
: What other good ways are there of representing type?
Inheritance: The inheritance hierarchy is well-represented with a tree diagram such as can be drawn in UML (though I have seen UML diagrams expressing inheritance without tree-ness.
: An outline display is also a fair way of expressing inheritance, though it can be hard to see the nesting if it's a complex hierarchy. The hierarchy can't express multiple inheritance. Hierarchy browsers make use of the outline display.