The Unified Modeling Language User Guide SECOND EDITION [Electronic resources]

Grady Booch, James Rumbaugh, Ivar Jacobson

نسخه متنی -صفحه : 215/ 69
نمايش فراداده

Getting Started

Dog houses aren't complex: you have four walls, one of them with a dog-size hole, and a roof. When you build a dog house, you really need only a small pile of lumber. There's not a lot more structure than that.

The differences between building a dog house and building a high rise are discussed in Chapter 1 .

Houses are more complex. Walls, ceilings, and floors come together in larger abstractions that we call rooms. Even these rooms are organized into larger chunks: the public area, the sleeping area, the working area, and so on. These larger groups may not manifest themselves as anything to do with the physical house itself but may just be names we give to logically related rooms in the house, which we apply when we talk about how we'll use the house.

High rise buildings are very complex. Not only are there elementary structures, such as walls, ceilings, and floors, but there are larger chunks, such as public areas, the retail wing, and office spaces. These chunks are probably grouped into even larger chunks, such as rental space and building service area. These larger chunks may have nothing to do with the final high rise itself but are simply artifacts we use to organize our plans for the high rise.

Every large system is layered in this way. In fact, about the only way you can understand a complex system is by chunking your abstractions into ever-larger groups. Most of these modest-size chunks (such as rooms) are, in their own right, class-like abstractions for which there are many instances. Most of these larger chunks are purely conceptual (such as a retail wing), for which there are no real instances. They are not distinct objects in the physical system but, rather, they represent views on the system itself. These latter kinds of chunks have no separate identity in the deployed system; they represent groupings of parts selected across the system.

In the UML, the chunks that organize a model are called packages. A package is a general-purpose mechanism for organizing elements into groups. Packages help you organize the elements in your models so that you can more easily understand them. Packages also let you control access to their contents so that you can control the seams in your system's architecture.

Software architecture is discussed in Chapter 2; modeling the architecture of a system is discussed in Chapter 32 .

The UML provides a graphical representation of package, as Figure 12-1 shows. This notation permits you to visualize groups of elements that can be manipulated as a whole and in a way that lets you control the visibility of and access to individual elements.

Figure 12-1. Packages