2.6 Documents

A UML document is a grouping of sections about a common subject, including any non-UML diagrams, textual documents, and other supporting information. UML documents are models. For example, the English language groups sections into documents, such as this book. A model is a representation of a system. For example, all the figures in this chapter and their supporting textual documentation are a model of the project management system. The elements that make up a model are known as model elements. For example, any element used on the diagrams in this chapter, with any supporting documentation necessary for communicating about that element, forms a model element.

The relationship between models, architectural views, and diagrams is similar to the relationship between databases, views, and queries. A database houses data, views organize subsets of the data into meaningful information, and queries extract subsets of the information. A model element is similar to a data element in the database, view elements are similar to data elements used within views, and diagram elements are similar to data elements used within queries. This establishes a general scheme or approach for how the UML is organized and how it allows us to communicate.

Because the UML is a language and not a methodology, it does not prescribe any explicit steps for applying models to develop a system given its requirements, but any methodology may generally address the models in association with these architectural views.

Models and diagrams help us capture and communicate our understanding of the requirements and system throughout the system development lifecycle process. They not only enable us to manage change and complexity, but also to assess our understanding before spending resources in producing a system that is unacceptable or does not sufficiently satisfy the requirements. Models capture all the detail in crossing the chasm between requirements and systems; we surely don't capture design and implementation details in the requirements, and we surely don't capture detailed requirements in the implementation of the system. However, we capture such details in a model that matures throughout a process as our understanding of the requirements and system likewise mature.