Building a dog house doesn't take a lot of thought. The needs of a dog are simple, so to satisfy all but the most demanding dog, you can just do it.
Building a house or a high rise takes a lot more thought. The needs of a family or a building's tenants are not so simple, so to satisfy even the least demanding client, you can't just do it. Rather, you have to do some modeling. Different stakeholders will look at the problem from different angles and with different concerns. That's why, for complex buildings, you'll end up creating floor plans, elevation plans, heating/cooling plans, electrical plans, plumbing plans, and perhaps even networking plans. There's no one model that can adequately capture all the interesting aspects of a complex building.
|
The differences between building a dog house and building a high rise are discussed in Chapter 1 |
In the UML, you organize all the abstractions of a software-intensive system into models, each of which represents some relatively independent, yet important, aspect of the system under development. You then use diagrams to visualize interesting collections of these abstractions. Looking at the five views of an architecture is a particularly useful way to channel the attention of a software system's different stakeholders. Collectively, these models work together to provide a complete statement of a system's structure and behavior.
|
Diagrams are discussed in Chapter 7; the five views of a software architecture are discussed in Chapter 2 |
For larger systems, you'll find that the elements of such systems can be meaningfully decomposed into separate subsystems, each of which looks just like a smaller system when viewed from a lower level of abstraction.
The UML provides a graphical representation for systems and subsystems, as Figure 32-1 shows. This notation permits you to visualize the decomposition of a system into smaller subsystems. Graphically, a system and a subsystem are rendered as a stereotyped component icon. Models and views have a special graphical representation (other than rendering them as stereotyped packages), but it is rarely used because they are primarily things that are manipulated by tools that you use to organize the different aspects of a system.
|
The UML's extensibility mechanisms are discussed in Chapter 6; packages are discussed in Chapter 12 |