UML packages and inter-package dependencies can be convenient both for describing architectural patterns and presenting architectural views. Fowler talks about package diagrams, but UML tools such as Visio may offer packages only as part of deployment diagrams. In architecture and pattern diagrams featuring packages, the packages don't have to literally represent packages in a programming language; it's enough to let them represent some set of related capabilities.

For example, here is a package diagram that captures the Model/View/Controller architectural pattern. See Fowler, Chapter 14 for details. Notice how abstract it is: there's nothing in it that connects to any particular application, or even a class of applications. It certainly is the core of a solution that can be (and has been) used thousands of times without ever doing it exactly the same way twice.

Here is a diagram that captures one way to partition responsibilities in a DVR system, consistent with MVC. The input drivers and DVR controller make up the Controller; the GUI and video driver make up the view; and the media library and various types of media are the model. (as always, I don't claim to be an expert on video, so there could be serious technical problems with this view). In BCK terms, this is a module view, because it presents a build-time-visible software structure.

The diagram above is still fairly abstract. An implementation-level UML class diagram would decompose it further into real packages and classes. Actually, for space reasons, the team would probably use several class diagrams to present an implementation for this architectural view.