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

Common Modeling Techniques

Modeling Executables and Libraries

The most common purpose for which you'll use artifacts is to model the deployment artifacts that make up your implementation. If you are deploying a trivial system whose implementation consists of exactly one executable file, you will not need to do any artifact modeling. If, on the other hand, the system you are deploying is made up of several executables and associated object libraries, doing artifact modeling will help you to visualize, specify, construct, and document the decisions you've made about the physical system. Artifact modeling is even more important if you want to control the versioning and configuration management of these parts as your system evolves.

For most systems, these deployment artifacts are drawn from the decisions you make about how to segment the physical implementation of your system. These decisions will be affected by a number of technical issues (such as your choice of artifact-based operating system facilities), configuration management issues (such as your decisions about which parts will likely change over time), and reuse issues (that is, deciding which artifacts you can reuse in or from other systems).

To model executables and libraries,

• 
  Identify the partitioning of your physical system. Consider the impact of technical, configuration management, and reuse issues.

  
  

• 
  Model any executables and libraries as artifacts, using the appropriate standard elements. If your implementation introduces new kinds of artifacts, introduce a new appropriate stereotype.

  
  

• 
  If it's important for you to manage the seams in your system, model the significant interfaces that some artifacts use and others realize.

  
  

• 
  As necessary to communicate your intent, model the relationships among these executables, libraries, and interfaces. Most often, you'll want to model the dependencies among these parts to visualize the impact of change.

  
  

For example, Figure 26-4 shows a set of artifacts drawn from a personal productivity tool that runs on a single personal computer. This figure includes one executable (animator.exe) and four libraries (dlog.dll, wrfrme.dll, render.dll, and raytrce.dll), all of which use the UML's standard elements for executables and libraries, respectively. This diagram also presents the dependencies among these artifacts.

As your models get bigger, you will find that many artifacts tend to cluster together in groups that are conceptually and semantically related. In the UML, you can use packages to model these clusters of artifacts.

For larger systems that are deployed across several computers, you'll want to model the way your artifacts are distributed by asserting the nodes on which they are located.

Modeling Tables, Files, and Documents

Modeling the executables and libraries that make up the physical implementation of your system is useful, but often you'll find there are a host of ancillary deployment artifacts that are neither executables nor libraries and yet are critical to the physical deployment of your system. For example, your implementation might include data files, help documents, scripts, log files, initialization files, and installation/removal files. Modeling these artifacts is an important part of controlling the configuration of your system. Fortunately, you can use UML artifacts to model all of these artifacts.

To model tables, files, and documents,

• 
  Identify the ancillary artifacts that are part of the physical implementation of your system.

  
  

• 
  Model these things as artifacts. If your implementation introduces new kinds of artifacts, introduce a new appropriate stereotype.

  
  

• 
  As necessary to communicate your intent, model the relationships among these ancillary artifacts and the other executables, libraries, and interfaces in your system. Most often, you'll want to model the dependencies among these parts in order to visualize the impact of change.

  
  

For example, Figure 26-5 builds on the previous figure and shows the tables, files, and documents that are part of the deployed system surrounding the executable animator.exe. This figure includes one document (animator.hlp), one simple file (animator.ini), and one database table (shapes.tbl). This example illustrates some user-defined stereotypes and icons for artifacts.

Modeling databases can get complicated when you start dealing with multiple tables, triggers, and stored procedures. To visualize, specify, construct, and document these features, you'll need to model the logical schema as well as the physical databases.

Modeling Source Code

The most common purpose for which you'll use artifacts is to model the physical parts that make up your implementation. The second most common purpose for which you'll use artifacts is to model the configuration of all the source code files that your development tools use to create these artifacts. These represent the work product artifacts of your development process.

Modeling source code graphically is particularly useful for visualizing the compilation dependencies among your source code files and for managing the splitting and merging of groups of these files when you fork and join development paths. In this manner, UML artifacts can be the graphical interface to your configuration management and version control tools.

For most systems, source code files are drawn from the decisions you make about how to segment the files your development environment needs. These files are used to store the details of your classes, interfaces, collaborations, and other logical elements as an intermediate step to creating the physical, binary artifacts that are derived from these elements by your tools. Most of the time these tools will impose a style of organization (one or two files per class is common), but you'll still want to visualize the relationships among these files. How you organize groups of these files using packages and how you manage versions of these files is driven by your decisions about how to manage change.

To model source code,

• 
  Depending on the constraints imposed by your development tools, model the files used to store the details of all your logical elements, along with their compilation dependencies.

  
  

• 
  If it's important for you to bolt these models to your configuration management and version control tools, you'll want to include tagged values, such as version, author, and check-in/check-out information, for each file that's under configuration management.

  
  

• 
  As far as possible, let your development tools manage the relationships among these files, and use the UML only to visualize and document these relationships.

  
  

For example, Figure 26-6 shows some source code files that are used to build the library render.dll from the previous examples. This figure includes four header files (render.h, rengine.h, poly.h, and colortab.h) that represent the source code for the specification of certain classes. There is also one implementation file (render.cpp) that represents the implementation of one of these headers.

As your models get bigger, you will find that many source code files tend to cluster together in groups that are conceptually and semantically related. Most of the time, your development tools will place these groups in separate directories. In the UML, you can use packages to model these clusters of source code files.