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.
Question
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.
Best Answer
If you're willing to broaden your search, I would possibly consider the SysML Block Definition Diagram (which is derived from the UML Composite Structure Diagram). There's no specific granularity for a block - it could be another system, a subsystem, component, class, and so on. SysML is an extension and modification to a subset of UML, so I don't think it would be large leap to consider bringing in elements of SysML if you are communicating with people already familiar with UML.
If you want to stay within UML, I wouldn't dismiss package diagrams so quickly. Although you are right that they normally correspond to something like Java's packages or C++'s namespace or a directory structure, they don't need to be used in that way. What you are describing could be viewed, from one perspective, as a "package". Scott Ambler's discussion of package diagrams in Agile Modeling supports this perspective, as well.
Personally, I don't have a problem mixing notations. In IEEE 1016:2009, which defines standards for describing software system designs, designs are captured from various viewpoints. A viewpoint shows the design from the perspective of a particular stakeholder, using one or more views. Views can be in any form, but are usually graphical (and sometimes tabular) with supporting text. The standard says that "only standardized and well-established (i.e., previously designed and conveniently available) design languages shall be used in an SDD" and does not restrict you to one design language. If your audience will understand the Coad-Yourdon notation or you can point them toward a reference source that they can easily obtain, use that notation.