In the object-oriented analysis approach defined in Object-Oriented Analysis by Peter Coad / Edward Yourdon (Yourdon Press, 1991), a method is provided for analysing and modelling complex problem domains using "subjects".
A subject is a group of closely related classes & objects that are represented as a single entity in order to simplify the model. Typically, a subject would represent the top level of a gen-spec or a whole-part class tree. For this reason, subject diagrams are useful as a 'top-level' view to guide the programmer through to more detailed class diagrams for each 'subject' area.
This would be a useful analytical approach for a project I am currently working on (it is a rather large problem domain).
In the book, a notation is suggested for use along with the analysis approach as it was recognised that an analytical method needs a supporting notation for it to be practical. However, the notation advocated as part of Peer Coad / Edward Yourdon's OOA approach was mostly superseded by the introduction of UML soon after.
In UML, how should Subject Diagrams be modelled?
Considerations thus far
My first thought was for component diagrams, but I have always viewed components as principally an implementation concern rather than part of the problem domain. Whilst the component definitions will usually coincide with natural divisions in the problem domain, it seems incorrect to be talking about interfaces etc. as part of the problem domain analysis.
I also considered package diagrams but this also seems inappropriate. I use package diagrams as part of deciding how the components are to be grouped in terms of the source code repositories; this is closely related to my deployment strategy as each package will be intended for deployment to a particular server.
So, is there a 'Subject Diagram' equivalent in UML? If not, I can use the Peter Coad / Edward Yourdon notation or even just a simplified class diagram; but I wanted to make sure their wasn't something in UML that I was missing... it is unified after all.