Microsoft .NET: Architecting Applications for the Enterprise ... - BattleIT

Chapter 1 Architects and Architecture Today 7
(with a specifi ed name) that is executed by the element where the connector starts and that
affects the target. So, for example, the System fulfi lls one or more Missions; the Environment
(context) infl uences the System; a Concern is important to one or more Stakeholders; the
System has an Architecture.
Describing the Architecture
As you can see in Figure 1-1, the Architecture is described by one Architectural Description.
How would you describe the architecture to stakeholders?
The key messages about an architecture are its components and classes, their mapping onto
binaries, their relationships and dependencies, usage scenarios, and detailed work fl ows for
key operations. How would you render all these things?
A very popular choice is UML diagrams.
UML is also a recognized international standard—precisely, ISO/IEC 19501 released in
2005. You create UML class diagrams to show relationships between classes; you employ
use-case diagrams to present usage scenarios; you create component diagrams to capture
the relationships between reusable parts of a system (components) and see more easily how
to map them onto binaries. In some cases, you can also add some sequence diagrams to
illustrate in more detail the workfl ow for some key scenarios. These terms are defi ned and
discussed in more detail in Chapter 2, “UML Essentials.”
At the end of the day, you serve different and concurrent views of the same architecture and
capture its key facts.
Note The same principle of offering multiple views from distinct viewpoints lies behind another
vendor-specifi c model for architectural description—IBM/Rational’s 4+1 views model. The model
defi nes four main views—nearly equivalent to UML diagrams. These views are as follows:
The logical view, which describe components
The process view, which describes mapping and dependencies
The development view, which describes classes
The physical view, which (if necessary) describes mapping onto hardware
The fi fth, partially redundant, view is the scenario view, which is specifi c to use cases.
Validating the Architecture
How would you validate the design to ensure that stakeholders’ concerns are properly
addressed?
There’s no magic wand and no magic formulas that take a more or less formal defi nition
of an architecture as input and tells you whether it is appropriate for the expressed