The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Common Modeling Techniques

Modeling the Architecture of a System

The most common use for which you'll apply systems and models is to organize the elements you use to visualize, specify, construct, and document a system's architecture. Ultimately, this touches virtually all the artifacts you'll find in a software development project. When you model a system's architecture, you capture decisions about the system's requirements, its logical elements, and its physical elements. You'll also model both structural and behavioral aspects of the systems and the patterns that shape these views. Finally, you'll want to focus on the seams between subsystems and the tracing from requirements to deployment.

To model the architecture of a system,

• Identify the views that you'll use to represent your architecture. Most often, you'll want to include a use case view, a design view, an interaction view, a implementation view, and a deployment view, as shown in Figure 32-3.

  Figure 32-3. Modeling a System's Architecture

  
  

  [View full size image]

  

• Specify the context for this system, including the actors that surround it.

As necessary, decompose the system into its elementary subsystems.

The following activities apply to the system, as well as to its subsystems.

• Specify a use case view of the system, encompassing the use cases that describe the behavior of the system as seen by its end users, analysts, and testers. Apply use case diagrams to model static aspects, and interaction diagrams, state diagrams, and activity diagrams to model the dynamic aspects.

• Specify a design view of the system, encompassing the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution. Apply class diagrams and object diagrams to model static aspects, and iteration diagrams, state diagrams, and activity diagrams to model the dynamic aspects.

• Specify an interaction view of the system, encompassing the threads, processes, and messages that form the system's concurrency and synchronization mechanisms. Apply the same diagrams as for the design view, but with a focus on active classes and objects that represent threads and processes as well as on messages and flow of control.

• Specify an implementation view of the system, encompassing the artifacts that are used to assemble and release the physical system. Apply artifact diagrams to model static aspects, and interaction diagrams, state diagrams, and activity diagrams to model the dynamic aspects.

• Specify a deployment view of the system, encompassing the nodes that form the system's hardware topology on which the system executes. Apply deployment diagrams to model static aspects, and interaction diagrams, state diagrams, and activity diagrams to model the dynamic aspects of the system in its execution environment.

• Model the architectural patterns and design patterns that shape each of these models using collaborations.

Understand that you don't ever create a system's architecture in one big-bang event. Rather, a well-structured process for the UML involves the successive refinement of a system's architecture in a manner that is use casedriven, architecture-centric, and iterative and incremental.

For all but the most trivial systems, you'll have to manage versions of your system's artifacts. You can use the UML's extensibility mechanismsand tagged values in particularto capture your decisions about the version of each element.

Modeling Systems of Systems

A system at one level of abstraction will look like a subsystem of a higher level of abstraction. Similarly, a subsystem at one level of abstraction will look like a full-fledged system from the perspective of the team responsible for creating it.

All complex systems exhibit this kind of hierarchy. As you move to systems of greater and greater complexity, you'll find it necessary to decompose your effort into subsystems, each of which can be developed somewhat separately, and iteratively and incrementally grown into the whole system. The development of a subsystem looks just like the development of a system.

To model a system or a subsystem,

• Identify major functional parts of the system that may be developed, released, and deployed somewhat independently. Technical, political, legacy, and legal issues will often shape how you draw the lines around each subsystem.

• For each subsystem, specify its context, just as you do for the system as a whole; the actors that surround a subsystem encompass all its neighboring subsystems, so they must all be designed to collaborate.

• For each subsystem, model its architecture just as you do for the system as a whole.