10.2 Documenting a View

Team-Fly     Documenting Software Architectures: Views and Beyond By Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, Judith Stafford Table of Contents Chapter 10.  Building the Documentation Package 10.2 Documenting a View Recall from Section 6.1 that a view consists of a set of view packets that are related by sibling and parent/child relationships. Documenting a view, then, becomes a matter of documenting a series of view packets. No matter what the view, the documentation for a view packet can be placed into a standard organization consisting of seven parts. FOR MORE INFORMATION Descriptive completeness is discussed in Section 6.1. The primary presentation shows the elements and relationships among them that populate the portion of the view shown in this view packet. The primary presentation should contain the information you wish to convey about the system�in the vocabulary of that view�first. It should certainly include the primary elements and relations but under some circumstances might not include all of them. For example, you may wish to show the elements and relations that come into play during normal operation but relegate error handling or exception processing to the supporting documentation. What information you include in the primary presentation may also depend on what notation you use and how conveniently it conveys various kinds of information. A richer notation will tend to enable richer primary presentations. or points to an explanation of the notation used in the presentation. The primary presentation is usually graphical. If so, this presentation must be accompanied by a key that explains Sometimes, the primary presentation can be textual, as we saw in Figure 2.2 on page 58. If the primary presentation is textual instead of graphical, it still carries the obligation to present a terse summary of the most important information in the view packet. If that text is presented according to certain stylistic rules, they should be stated or incorporated by reference, as the analog to the graphical notation key. ADVICE Every diagram in the architecture documentation should include a key that explains the meaning of every symbol used. The first part of the key should identify the notation. If a defined notation is being used, the key should name it and cite the document that defines the version being used. Otherwise, the key should define the symbology and the meaning, if any, of colors, position, or other information-carrying aspects of the diagram. The element catalog details at least those elements depicted in the primary presentation and perhaps others; see the discussion of descriptive completeness in Section 6.1. For instance, if a diagram shows elements A, B, and C, documentation is needed that explains in sufficient detail what A, B, and C are and their purposes or the roles they play, rendered in the vocabulary of the view. In addition, if elements or relations relevant to this view packet were omitted from the primary presentation, they should be is introduced and explained in the catalog. Specific parts of the catalog include Elements and their properties. This section names each element in the view packet and lists the properties of that element. In Part I, each view we introduced listed a set of properties associated with elements in that view. For example, elements in a module decomposition view have the property of "responsibility"�an explanation of each module's role in the system�and elements in a communicating-processes view have timing parameters, among other things, as properties. Whether the properties are generic to the kind of view chosen or the architect has introduced new ones, this is where they are documented and given values. Relations and their properties. Each view has specific relation type(s) that it depicts among the elements in that view. Mostly, these relations are shown in the primary presentation. However, if the primary presentation does not show all the relations or if there are exceptions to what is depicted in the primary presentation, this is the place to record that information. Element interfaces. An interface is a boundary across which elements interact or communicate with each other. This section documents element interfaces. An element might occur in more than one view packet or even more than one view. Where its interface is documented is a packaging question, decided on the basis of convenience and addressing the needs of stakeholders. Different aspects of the interface may be captured and documented in different views. Or you may wish to document the interfaces in a single document, in which case this section consists of a pointer. Element behavior. Some elements have complex interactions with their environment. For purposes of understanding or analysis, it is often incumbent on the architect to specify element behavior. A context diagram shows how the system or portion of the system depicted in this view packet relates to its environment. A variability guide shows how to exercise any variation points that are a part of the architecture shown in this view packet. Architecture background explains why the design reflected in the view packet came to be. The goal of this section is to ex-plain why the design is as it is and to provide a convincing argument that it is sound. Architecture background includes Rationale. The architect explains why the design decisions reflected in the view packet were made and gives a list of rejected alternatives and why they were rejected. This information will prevent future architects from pursuing dead ends in the face of required changes. Analysis results. The architect should document the results of analyses that have been conducted, such as the results of performance or security analysis or a list of what would have to change in the face of a particular kind of system modification. Assumptions. The architect should document any assumptions he or she made when crafting the design. Assumptions are usually about either environment or need. Assumptions about the environment document what the architect assumes is available in the environment and what can be used by the system being designed. Assumptions are also made about invariants in the environment. For example, a navigation system architect might make assumptions about the stability of the earth's geographic and/or magnetic poles. Finally, assumptions about the environment can pertain to the development environment: tool suites available or the skill levels of the implementation teams, for example. Assumptions about need state why the design provided is sufficient for what's needed. For example, if a navigation system's software interface provides location information in a single geographic frame of reference, the architect is assuming that it is sufficient and that alternative frames of reference are not useful. Assumptions can play a crucial role in the validation of an architecture. The design that an architect produces is a function of these assumptions, and writing them down explicitly makes it vastly easier to review them for accuracy and soundness than trying to ferret them out by examining the design. Other information provided will vary according to the standard practices of each organization or the needs of the particular project. If the view packet is maintained as a separate document, you can use this section to record document information (see Section 10.1). Or the architect might record references to specific sections of a requirements document to establish traceability. Information in this section is, strictly speaking, not architectural. Nevertheless, it is convenient to record such information alongside the architecture, and this section is provided for that purpose. Related view packets are the parent, siblings, and any children. In some cases, a view packet's children may reside in a different view, as when an element in one style is decomposed into a set of elements in a different style. FOR MORE INFORMATION Documenting interfaces is covered in Chapter 7. FOR MORE INFORMATION Documenting behavior is discussed in Chapter 8. FOR MORE INFORMATION Context diagrams are discussed in Section 6.2. FOR MORE INFORMATION Documenting variability is discussed in Section 6.4. Items 2�7, the supporting documentation, explain and elaborate the information in the primary presentation. Even if some items are empty for a given view packet�for example, perhaps no mechanisms for variability exist or no relations other than those shown in the primary presentation exist�include those sections, marked "none." Don't omit them, or your reader may wonder whether it was an oversight. DEFINITION An architectural cartoon is the graphical portion of a view's primary presentation, without supporting documentation. Every view packet, then, consists of a primary presentation, usually graphical, and supporting documentation that explains and elaborates the pictures (see Figure 10.1). To underscore the complementary nature of the primary presentation with its supporting documentation, we call the graphical portion of the view packet an architectural cartoon. We use the definition from the world of fine art: A cartoon is a preliminary sketch of the final work; it is meant to remind us that the picture, although getting most of the attention, is not the complete description but only a sketch of it. In fact, it may be considered merely an introduction to or a quick summary of the information provided by the supporting documentation. Figure 10.1. Documenting a view packet consists of documenting seven parts: (1) the primary presentation; (2) the element catalog; (3) a context diagram; (4) a variability guide; (5) architecture background, including rationale, results of analysis, and assumptions made; (6) organization- or project-specific information; and (7) pointers to the view packet's siblings, parent(s), or children. If the primary presentation is graphical, we call it a cartoon. A cartoon must be accompanied by a key that explains the notational symbology used or that points to the place where the notation is explained. PERSPECTIVES Presentation Is Also Important Throughout this book, we focus on telling you what to document. We do not spend much, if any, time on how it should look, although this is not because form is unimportant. Just as the best-designed algorithm can be made to run slowly by insufficient attention to detail during coding, so too the best-designed documentation can be made difficult to read by insufficient attention to presentation details. By presentation details, I mean such items as style of writing, fonts, types and consistency of visual emphasis, and the segmenting of information. We have not spent time on these issues not because we do not think they are important but because presentation details are not our field of expertise. Universities offer master's degrees in technical communication, in information design, and in other fields related to the presentation of material. We have been busy being software engineers and architects and have never been trained in presentation issues. Having denied expertise, however, I am now free to give some rules of thumb. Adopt a style guide for the documentation. The style guide will specify such items as fonts, numbering schemes, conventions with respect to acronyms, captions for figures, and other such details. The style guide should also describe how to use the visual conventions discussed in the next several points. Use visually distinct forms for emphasis. Word processors offer many techniques for emphasis. Words can be bold, italic, large, or underlined. Using these forms makes some words more important than others. Be consistent in using visual styles. Use one visual style for one purpose, and do not mix purposes. That is, the first use of a word might be italicized, and a critical thought might be expressed in bold, but do not use the same style for both purposes, and do not mix styles. Do not go overboard with visuals. It is usually sufficient to use one form of visual emphasis without combining them. Is bold less arresting to you than underlined bold? Probably not. Try to separate different types of ideas with different visual backgrounds. In this book, we attempted to put the main thread in the body of the book, with ancillary information as sidebars. We also made the sidebars visually distinct so that you would know at a glance whether what you were reading was in the main thread or an ancillary thread. The key ideas with respect to presentation are consistency and simplicity. Use the same visual language to convey the same idea: consistency. Do not try to overwhelm the user with visuals; you are documenting a computer system, not writing an interactive novel: shoot for simplicity. The goal of the architecture documentation, as we have stressed throughout this book, is to communicate the basic concepts of the system clearly to the reader. Using simple and consistent visual and stylistic rules is an important aspect of achieving this goal. �L.B. QUOTATION It may take you months, even years, to draft a single map. It's not just the continents, oceans, mountains, lakes, rivers, and political borders you have to worry about. There's also the cartouche (a decorative box containing printed information, such as the title and the cartographer's name) and an array of other adornments�distance scales, compass roses, wind-heads, ships, sea monsters, important personages, characters from the Scriptures, quaint natives, menacing cannibal natives, sexy topless natives, planets, wonders of the ancient world, flora, fauna, rainbows, whirlpools, sphinxes, sirens, cherubs, heraldic emblems, strapwork, rollwork, and/or clusters of fruit. �Miles Harvey, The Island of Lost Maps: A True Story of Cartographic Crime (Random House, 2000, p. 98) Team-Fly     Top

About the Author

[ Team LiB ]

About the Author Steve McConnell is CEO and Chief Software Engineer at Construx Software, where he writes books and articles, teaches classes, and oversees Construx's software engineering practices. He is the author of Code Complete (1993), Rapid Development (1996), and Software Project Survival Guide (1998). His books have twice won Software Development magazine's Jolt Excellence award for outstanding software development book of the year. In 1998, readers of Software Development magazine named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds. Steve was Editor in Chief of IEEE Software magazine from 1998�2002. He is on the Panel of Experts that advises the Software Engineering Body of Knowledge (SWEBOK) project and is Vice Chair of the IEEE Computer Society's Professional Practices Committee. Steve earned a bachelor's degree from Whitman College and a master's degree in software engineering from Seattle University. He lives in Bellevue, Washington. If you have any comments or questions about this book, please contact Steve at stevemcc@construx.com or via his Web site, www.stevemcconnell.com.

[ Team LiB ]

/etc/passwd, /etc/shadow, and Password Aging

/etc/passwd, /etc/shadow, and Password Aging One of the first things to do when troubleshooting a login failure is to confirm that the account exists. The finger command shows user information, but because /etc/passwd has read permissions for all, we prefer just to grep for the user name. $ grep bob /etc/passwd bob:x:515:515::/home/bob:/bin/bash We are only confirming that there is an /etc/passwd line for this user to prove that the account hasn't been removed. /etc/passwd and /etc/shadow Account information is stored in two files: /etc/passwd and /etc/shadow. All users can view the /etc/passwd file: $ ls -l /etc/passwd -rw-r--r-- 1 root root 2423 Jan 21 11:17 /etc/passwd The /etc/passwd file has seven fields, as shown in Table 14-1. Table 14-1. /etc/passwd Fields Field # Description 1 User name 2 Password 3 User ID 4 Group ID 5 Comment 6 Home directory 7 Login shell The /etc/passwd file is completely explained in the passwd(5) man page. We are interested in the password field for the purposes of this chapter. The password field does not contain the encrypted password. It should have an "x" instead. The password field did contain the password when UNIX was first released. As computers became more powerful, though, viewable encrypted passwords left systems vulnerable to brute force attacks. Thus, the password was moved to a new file that can only be read by root. This file is /etc/shadow. In Linux, the /etc/shadow file is delivered in the shadow-utils package. $ ls -l /etc/shadow -r-------- 1 root root 1974 Jan 22 13:30 /etc/shadow Let's look at the /etc/shadow entry for an account. The grep command is an easy way to view /etc/shadow. $ grep bob /etc/shadow grep: /etc/shadow: Permission denied Right. We must switch to root. #grep bob /etc/shadow bob:$1$lIDEzDIs$mVFLa6ZVsSolJS8yPc3/o.:12800:0:99999:7::: The /etc/shadow file contains password aging information as well as the password. The fields separated by ":" are explained in Table 14-2. Table 14-2. /etc/shadow Fields Field # Description 1 User name 2 Encrypted password 3 Date the password was last changed 4 Minimum age of password in days before it can be changed (0 by default) 5 Maximum age of password in days after which it must be changed (99999 by default) 6 The number of days before password expiration when user is warned to change the password (7 by default) 7 The number of days after password expiration when account login is disabled 8 The date when account login is disabled 9 Not used The /etc/shadow date fields are in days since January 1st, 1970. The password expiration date is the result of adding the date the password was last changed field and the maximum age of password field. See the shadow(5) man page for more details. chage, passwd, and usermod The chage, passwd, and usermod commands can be used to modify password aging parameters. The usermod command duplicates some but not all the password aging features of chage. The chage -l username syntax is a good way to view the password aging settings for accounts. The following example shows the default password aging information for an account: #chage -l bob Minimum: 0 field 4 /etc/shadow Maximum: 99999 field 5 /etc/shadow Warning: 7 field 6 /etc/shadow Inactive: -1 field 7 /etc/shadow Last Change: Jan 17, 2005 field 3 /etc/shadow Password Expires: Never field 3 + field 5 Password Inactive: Never field 3 + field 5 + field 7 Account Expires: Never field 8 /etc/shadow Let's look at the password aging example. A user tries to log in on January 19, 2005 using ssh, but the term window is disconnected immediately after entering the password: login as: dbadmin3 Sent username "dbadmin3" TIS authentication refused. lori@sawnee.somecomp.com's password: The login attempt doesn't identify the problem. The chage -l username command shows that the account expired yesterday, preventing logins. #chage -l dbadmin3 Minimum: 0 Maximum: 99999 Warning: 7 Inactive: -1 Last Change: Jan 17, 2005 Password Expires: Never Password Inactive: Never Account Expires: Jan 18, 2005 The Password Inactive and Account Expires dates prevent a user from logging in. When the Password Expires date is reached, the user should be forced to change his or her password during login. However, ssh will just fail the login attempt. Table 14-3 shows the more useful chage syntaxes. Table 14-3. chage Syntax Syntax Description chage -l <username> Display password aging values chage -m ## <username> Change minimum password lifetime chage -M ## <username> Change maximum password lifetime chage -I ## <username> Number of days after password expiration when account login is disabled chage -E <date> <username> Set account expiration date chage -W ## <username> Set number of days before password expiration to warn user that password will expire chage -d <date> <username> Set last password change date Dates are in YYYY-MM-DD format, 2005-01-19 for example. The ## in the table indicates a number of days parameter. Here is an example showing a change to the maximum password lifetime. Password lifetime is field 5 of /etc/shadow. #grep dbadmin /etc/shadow dbadmin:$1$TuCLLDqz$Fc1YnK309QXT6TJMOagdZ.:12841:0:99999:7::: We can use grep to see this information, but chage is nicer. #chage -l dbadmin Minimum: 0 Maximum: 99999 Warning: 7 Inactive: -1 Last Change: Feb 27, 2005 Password Expires: Never Password Inactive: Never Account Expires: Never Now let's set the maximum password lifetime using chage. #chage -M 30 dbadmin We can use grep to see that the password aging field is now 30. #grep dbadmin /etc/shadow dbadmin:$1$TuCLLDqz$Fc1YnK309QXT6TJMOagdZ.:12841:0:30:7::: Once again, chage -l username offers nicer output. # chage -l dbadmin Minimum: 0 Maximum: 30 Warning: 7 Inactive: -1 Last Change: Feb 27, 2005 Password Expires: Mar 29, 2005 Password Inactive: Never Account Expires: Never A -1 for either a date or days field clears the field from /etc/shadow. Here is an example demonstrating how to reset the Account Expires date, which is field 8. Once again, we look at the password aging information with both grep and chage so that we can clearly see which field is being changed. #grep lori /etc/shadow lori:$1$cQG1pnOz$UHRmboguvqvOyJv5wAbTr/:12805:0:30:7::12847: chage -l lori Minimum: 0 Maximum: 30 Warning: 7 Inactive: -1 Last Change: Jan 22, 2005 Password Expires: Feb 21, 2005 Password Inactive: Never Account Expires: Mar 05, 2005 Here chage is used to clear the account expiration date. #chage -E -1 lori #chage -l lori Minimum: 0 Maximum: 30 Warning: 7 Inactive: -1 Last Change: Jan 22, 2005 Password Expires: Feb 21, 2005 Password Inactive: Never Account Expires: Never Field 8 is empty. #grep lori /etc/shadow lori:$1$cQG1pnOz$UHRmboguvqvOyJv5wAbTr/:12805:0:30:7::: The usermod command can set the account expiration date and the number of days after the password expires when the account is locked. The syntax is shown for each in Table 14-4. Table 14-4. usermod Password Aging Syntax Syntax Description usermod -e <date> <username> Set account expiration date; same as chage -E usermod -f ## <username> Set number of days of inactivity before account login is disabled; same as chage -I The following example is similar to the previous chage example. This time, usermod is used to change the account expiration date, which is field 8 in /etc/shadow. #grep dbadmin /etc/shadow dbadmin:$1$TuCLLDqz$Fc1YnK309QXT6TJMOagdZ.:12841:0:30:7::: chage -l dbadmin Minimum: 0 Maximum: 30 Warning: 7 Inactive: -1 Last Change: Feb 27, 2005 Password Expires: Mar 29, 2005 Password Inactive: Never Account Expires: Never #usermod -e 2006-01-03 dbadmin #grep dbadmin /etc/shadow dbadmin:$1$TuCLLDqz$Fc1YnK309QXT6TJMOagdZ.:12841:0:30:7::13151: #chage -l dbadmin Minimum: 0 Maximum: 30 Warning: 7 Inactive: -1 Last Change: Feb 27, 2005 Password Expires: Mar 29, 2005 Password Inactive: Never Account Expires: Jan 03, 2006 Let's remove the Account Expires date: #chage -E -1 dbadmin #grep dbadmin /etc/shadow dbadmin:$1$TuCLLDqz$Fc1YnK309QXT6TJMOagdZ.:12841:0:30:7::: #chage -l dbadmin Minimum: 0 Maximum: 30 Warning: 7 Inactive: -1 Last Change: Feb 27, 2005 Password Expires: Mar 29, 2005 Password Inactive: Never Account Expires: Never The passwd command can change the password aging fields too. The passwd aging options are shown in Table 14-5. Table 14-5. passwd Password Aging Syntax Description passwd -n ## <username> Minimum password lifetime; same as chage -m passwd -x ## <username> Maximum password lifetime; same as chage -M passwd -w ## <username> Set number of days before password expiration to warn user that password will expire; same as chage -W passwd -i ## <username> Number of days after password expiration when account login is disabled; same as chage -I The ## in the table indicates a number of days parameter. A -1 for the ## (days field) will clear the field from /etc/shadow like chage. The usermod and passwd commands can also disable an account. The different syntaxes are shown in Table 14-6. Table 14-6. Locking Accounts Syntax Description usermod -L <username> Lock the account usermod -U <username> Unlock the account passwd -l <username> Lock the account passwd -u <username> Unlock the account A ! in the password field of /etc/shadow indicates a locked account. Notice the change in the password field after usermod is used to lock an account. #grep dbadmin /etc/shadow dbadmin:$1$TuCLLDqz$Fc1YnK309QXT6TJMOagdZ.:12841:0:30:7::: #usermod -L dbadmin grep dbadmin /etc/shadow dbadmin:!$1$TuCLLDqz$Fc1YnK309QXT6TJMOagdZ.:12841:0:30:7::: The chage -l output doesn't indicate that the account is locked. #chage -l dbadmin Minimum: 0 Maximum: 30 Warning: 7 Inactive: -1 Last Change: Feb 27, 2005 Password Expires: Mar 29, 2005 Password Inactive: Never Account Expires: Never The account can be unlocked with usermod -U, passwd -u, or by changing the password with the passwd command as root. Why can't the user change the password, assuming he or she is already logged in? Because the user is prompted for the current password before being granted the authority to change the password. The user doesn't know the password anymore because a ! character was added when the account was locked. Root isn't required to enter the current password, which enables the root user to unlock the account with passwd. The following is an example of a locked account being unlocked with passwd. #grep dbadmin /etc/shadow dbadmin:!$1$8nF5XmBG$Pckwi8Chld..JgP5Zmc4i0:12841:0:30:7::: #passwd -u dbadmin Unlocking password for user dbadmin. passwd: Success. #grep dbadmin /etc/shadow dbadmin:$1$8nF5XmBG$Pckwi8Chld..JgP5Zmc4i0:12841:0:30:7::: /etc/passwd and /etc/shadow Corruption The passwd and shadow files can be corrupted in numerous ways: /etc/shadow might have been restored while /etc/passwd was not, incorrect file permissions could cause problems, and so on. Let's look at what happens if someone edits /etc/shadow to clear password aging information while a user attempts to change his password. Look at Dave's /etc/shadow line: dave:$1$dkdAH.dQ$DU1t04WOFGjF4BGymI/ll0:12802:0:2:7::: The system administrator is using vi to edit /etc/shadow. Before the system administrator saves the file, Dave changes his password successfully by using the passwd command. /etc/shadow shows the change to the password field: dave:$1$VGCA.Vk8$9u2b8W5eCWjtOdt6ipOlD0:12804:0:2:7::: Now the system administrator saves /etc/shadow. When the administrator tries to save the file, he sees: WARNING: The file has been changed since reading it!!! Do you really want to write to it (y/n)? Hopefully, the system administrator replies n and tries again. If not, Dave loses his password change. Look at what happens to Dave's password. It changes back to the previous value: #grep dave /etc/shadow dave:$1$dkdAH.dQ$DU1t04WOFGjF4BGymI/ll0:12802:0:2:7::: Be careful when making changes to /etc/passwd or /etc/shadow. Always try to use a command to make changes instead of editing the file. pwck Linux provides the pwck command to look for /etc/passwd and /etc/shadow problems. This command validates field entries and looks for duplicate lines. No output from pwck means it didn't identify any problems. It will not find all problems, so you might need to inspect the passwd and shadow files line by line to confirm the lines are correct. The following error is caused by user rob not having an entry in /etc/shadow. The pwck command didn't catch it. passwd rob Changing password for user rob. passwd: Authentication token manipulation error

Section 4.1. The Build Process

4.1. The Build Process When build tools run on the same system as the program they produce, they can make a lot of assumptions about the system. This is typically not the case in embedded software development, where the build tools run on a host computer that differs from the target hardware platform. There are a lot of things that software development tools can do automatically when the target platform is well defined. [*] This automation is possible because the tools can exploit features of the hardware and operating system on which your program will execute. For example, if all of your programs will be executed on IBM-compatible PCs running Windows, your compiler can automateand, therefore, hide from your viewcertain aspects of the software build process. Embedded software development tools, on the other hand, can rarely make assumptions about the target platform. Instead, the user must provide some of her own knowledge of the system to the tools by giving them more explicit instructions. [*] Used this way, the term "target platform" is best understood to include not only the hardware but also the operating system that forms the basic runtime environment for your software. If no operating system is present, as is sometimes the case in an embedded system, the target platform is simply the processor on which your program runs. The process of converting the source code representation of your embedded software into an executable binary image involves three distinct steps: Each of the source files must be compiled or assembled into an object file. All of the object files that result from the first step must be linked together to produce a single object file, called the relocatable program. Physical memory addresses must be assigned to the relative offsets within the relocatable program in a process called relocation. The result of the final step is a file containing an executable binary image that is ready to run on the embedded system. The embedded software development process just described is illustrated in Figure 4-1. In this figure, the three steps are shown from top to bottom, with the tools that perform the steps shown in boxes that have rounded corners. Each of these development tools takes one or more files as input and produces a single output file. More specific information about these tools and the files they produce is provided in the sections that follow. Figure 4-1. The embedded software development process Each of the steps of the embedded software build process is a transformation performed by software running on a general-purpose computer. To distinguish this development computer (usually a PC or Unix workstation) from the target embedded system, it is referred to as the host computer. The compiler, assembler, linker, and locator run on a host computer rather than on the embedded system itself. Yet, these tools combine their efforts to produce an executable binary image that will execute properly only on the target embedded system. This split of responsibilities is shown in Figure 4-2. Figure 4-2. The split between host and target In this book, we'll be using the GNU tools (compiler, assembler, linker, and debugger) for our examples. These tools are extremely popular with embedded software developers because they are freely available (even the source code is free) and support many of the most popular embedded processors. We will use features of these specific tools as illustrations for the general concepts discussed. Once understood, these same basic concepts can be applied to any equivalent development tool. The manuals for all of the GNU software development tools can be found online at http://www.gnu.org/manual. 4.1.1. Compiling The job of a compiler is mainly to translate programs written in some human-readable language into an equivalent set of opcodes for a particular processor. In that sense, an assembler is also a compiler (you might call it an "assembly language compiler"), but one that performs a much simpler one-to-one translation from one line of human-readable mnemonics to the equivalent opcode. Everything in this section applies equally to compilers and assemblers. Together these tools make up the first step of the embedded software build process. Of course, each processor has its own unique machine language, so you need to choose a compiler that produces programs for your specific target processor. In the embedded systems case, this compiler almost always runs on the host computer. It simply doesn't make sense to execute the compiler on the embedded system itself. A compiler such as thisthat runs on one computer platform and produces code for anotheris called a cross-compiler. The use of a cross-compiler is one of the defining features of embedded software development. The GNU C compiler (gcc) and assembler (as) can be configured as either native compilers or cross-compilers. These tools support an impressive set of host-target combinations. The gcc compiler will run on all common PC and Mac operating systems. The target processor support is extensive, including AVR, Intel x86, MIPS, PowerPC, ARM, and SPARC. Additional information about gcc can be found online at http://gcc.gnu.org. Regardless of the input language (C, C++, assembly, or any other), the output of the cross-compiler will be an object file. This is a specially formatted binary file that contains the set of instructions and data resulting from the language translation process. Although parts of this file contain executable code, the object file cannot be executed directly. In fact, the internal structure of an object file emphasizes the incompleteness of the larger program. The contents of an object file can be thought of as a very large, flexible data structure. The structure of the file is often defined by a standard format such as the Common Object File Format (COFF) or Executable and Linkable Format (ELF). If you'll be using more than one compiler (i.e., you'll be writing parts of your program in different source languages), you need to make sure that each compiler is capable of producing object files in the same format; gcc supports both of the file formats previously mentioned. Although many compilers (particularly those that run on Unix platforms) support standard object file formats such as COFF and ELF, some others produce object files only in proprietary formats. If you're using one of the compilers in the latter group, you might find that you need to get all of your other development tools from the same vendor. Most object files begin with a header that describes the sections that follow. Each of these sections contains one or more blocks of code or data that originated within the source file you created. However, the compiler has regrouped these blocks into related sections. For example, in gcc all of the code blocks are collected into a section called text, initialized global variables (and their initial values) into a section called data, and uninitialized global variables into a section called bss. There is also usually a symbol table somewhere in the object file that contains the names and locations of all the variables and functions referenced within the source file. Parts of this table may be incomplete, however, because not all of the variables and functions are always defined in the same file. These are the symbols that refer to variables and functions defined in other source files. And it is up to the linker to resolve such unresolved references. 4.1.2. Linking All of the object files resulting from the compilation in step one must be combined. The object files themselves are individually incomplete, most notably in that some of the internal variable and function references have not yet been resolved. The job of the linker is to combine these object files and, in the process, to resolve all of the unresolved symbols. The output of the linker is a new object file that contains all of the code and data from the input object files and is in the same object file format. It does this by merging the text, data, and bss sections of the input files. When the linker is finished executing, all of the machine language code from all of the input object files will be in the text section of the new file, and all of the initialized and uninitialized variables will reside in the new data and bss sections, respectively. While the linker is in the process of merging the section contents, it is also on the lookout for unresolved symbols. For example, if one object file contains an unresolved reference to a variable named foo, and a variable with that same name is declared in one of the other object files, the linker will match them. The unresolved reference will be replaced with a reference to the actual variable. For example, if foo is located at offset 14 of the output data section, its entry in the symbol table will now contain that address. The GNU linker (ld) runs on all of the same host platforms as the GNU compiler. It is a command-line tool that takes the names of all the object files, and possibly libraries, to be linked as arguments. With embedded software, a special object file that contains the compiled startup code, which is covered later in this section, must also be included within this list. The GNU linker also has a scripting language that can be used to exercise tighter control over the object file that is output. If the same symbol is declared in more than one object file, the linker is unable to proceed. It will likely complain to the programmer (by displaying an error message) and exit. On the other hand, if a symbol reference remains unresolved after all of the object files have been merged, the linker will try to resolve the reference on its own. The reference might be to a function, such as memcpy, strlen, or malloc, that is part of the standard C library, so the linker will open each of the libraries described to it on the command line (in the order provided) and examine their symbol tables. If the linker thus discovers a function or variable with that name, the reference will be resolved by including the associated code and data sections within the output object file. [] Note that the GNU linker uses selective linking, which keeps other unreferenced functions out of the linker's output image. [] We are talking only about static linking here. When dynamic linking of libraries is used, the code and data associated with the library routine are not inserted into the program directly. Unfortunately, the standard library routines often require some changes before they can be used in an embedded program. One problem is that the standard libraries provided with most software development tool suites arrive only in object form. You only rarely have access to the library source code to make the necessary changes yourself. Thankfully, a company called Cygnus (which is now part of Red Hat) created a freeware version of the standard C library for use in embedded systems. This package is called newlib . You need only download the source code for this library from the Web (currently located at http://sourceware.org/newlib), implement a few target-specific functions, and compile the whole lot. The library can then be linked with your embedded software to resolve any previously unresolved standard library calls. After merging all of the code and data sections and resolving all of the symbol references, the linker produces an object file that is a special "relocatable" copy of the program. In other words, the program is complete except for one thing: no memory addresses have yet been assigned to the code and data sections within. If you weren't working on an embedded system, you'd be finished building your software now. But embedded programmers aren't always finished with the build process at this point. The addresses of the symbols in the linking process are relative. Even if your embedded system includes an operating system, you'll probably still need an absolutely located binary image. In fact, if there is an operating system, the code and data of which it consists are most likely within the relocatable program too. The entire embedded applicationincluding the operating systemis frequently statically linked together and executed as a single binary image. 4.1.2.1. Startup code One of the things that traditional software development tools do automatically is insert startup code: a small block of assembly language code that prepares the way for the execution of software written in a high-level language. Each high-level language has its own set of expectations about the runtime environment. For example, programs written in C use a stack. Space for the stack has to be allocated before software written in C can be properly executed. That is just one of the responsibilities assigned to startup code for C programs. Most cross-compilers for embedded systems include an assembly language file called startup.asm, crt0.s (short for C runtime), or something similar. The location and contents of this file are usually described in the documentation supplied with the compiler. Startup code for C programs usually consists of the following series of actions: Disable all interrupts. Copy any initialized data from ROM to RAM. Zero the uninitialized data area. Allocate space for and initialize the stack. Initialize the processor's stack pointer. Call main. Typically, the startup code will also include a few instructions after the call to main. These instructions will be executed only in the event that the high-level language program exits (i.e., the call to main returns). Depending on the nature of the embedded system, you might want to use these instructions to halt the processor, reset the entire system, or transfer control to a debugging tool. Because the startup code is often not inserted automatically, the programmer must usually assemble it himself and include the resulting object file among the list of input files to the linker. He might even need to give the linker a special command-line option to prevent it from inserting the usual startup code. Working startup code for a variety of target processors can be found in a GNU package called libgloss . Debug Monitors In some cases, a debug monitor (or ROM monitor) is the first code executed when the board powers up. In the case of the Arcom board, there is a debug monitor called RedBoot. [] RedBoot, the name of which is an acronym for RedHat's Embedded Debug and Bootstrap program, is a debug monitor that can be used to download software, perform basic memory operations, and manage nonvolatile memory. This software on the Arcom board contains the startup code and performs the tasks listed previously to initialize the hardware to a known state. Because of this, programs downloaded to run in RAM via RedBoot do not need to be linked with startup code and should be linked but not located. After the hardware has been initialized, RedBoot sends out a prompt to a serial port and waits for input from the user (you) to tell it what to do. RedBoot supports commands to load software, dump memory, and perform various other tasks. We will take a look at using RedBoot to load a software program in the next chapter. [] Additional information about RedBoot can be found online at http://ecos.sourceware.org/redboot. The RedBoot User's Guide is located on this site as well. A description of the RedBoot startup procedure is contained in the book Embedded Software Development with eCos, by Anthony Massa (Prentice Hall PTR). 4.1.3. Locating The tool that performs the conversion from relocatable program to executable binary image is called a locator. It takes responsibility for the easiest step of the build process. In fact, you have to do most of the work in this step yourself, by providing information about the memory on the target board as input to the locator. The locator uses this information to assign physical memory addresses to each of the code and data sections within the relocatable program. It then produces an output file that contains a binary memory image that can be loaded into the target. Whether you are writing software for a general-purpose computer or an embedded system, at some point the sections of your relocatable program must be assigned actual addresses. Sometimes software that is already in the target does this for you, as RedBoot does on the Arcom board. In some cases, there is a separate development tool, called a locator, to assign addresses. However, in the case of the GNU tools, this feature is built into the linker (ld). The memory information required by the GNU linker can be passed to it in the form of a linker script. Such scripts are sometimes used to control the exact order of the code and data sections within the relocatable program. But here, we want to do more than just control the order; we also want to establish the physical location of each section in memory. What follows is an example of a linker script for the Arcom board. This linker script file is used to build the Blinking LED program covered in Chapter 3: ENTRY (main) MEMORY { ram : ORIGIN = 0x00400000, LENGTH = 64M rom : ORIGIN = 0x60000000, LENGTH = 16M } SECTIONS { data : /* Initialized data. */ { _DataStart = . ; *(.data) _DataEnd = . ; } >ram bss : /* Uninitialized data. */ { _BssStart = . ; *(.bss) _BssEnd = . ; } >ram text : /* The actual instructions. */ { *(.text) } >ram } This script informs the GNU linker's built-in locator about the memory on the target board, which contains 64 MB of RAM and 16 MB of flash ROM. [§] The linker script file instructs the GNU linker to locate the data, bss, and text sections in RAM starting at address 0x00400000. The first executable instruction is designated with the ENtrY command, which appears on the first line of the preceding example. In this case, the entry point is the function main. [§] There is also a version of the Arcom board that contains 32 MB of flash. If you have this version of the board, change the linker script file as follows: rom : ORIGIN = 0x60000000, LENGTH = 32M Names in the linker command file that begin with an underscore (e.g., _DataStart) can be referenced similarly to ordinary variables from within your source code. The linker will use these symbols to resolve references in the input object files. So, for example, there might be a part of the embedded software (usually within the startup code) that copies the initial values of the initialized variables from ROM to the data section in RAM. The start and stop addresses for this operation can be established symbolically by referring to the addresses as _DataStart and _DataEnd. A linker script can also use various commands to direct the linker to perform other operations. Additional information and options for GNU linker script files can be found at http://www.gnu.org. The output of this final step of the build process is a binary image containing physical addresses for the specific embedded system. This executable binary image can be downloaded to the embedded system or programmed into a memory chip. You'll see how to download and execute such memory images in the next chapter.

Section 5.1. The Graphic Toolbox: Shapes, Layers, Gradient, and Blur

Chapter 5. Pop Graphics

Photographs are only part of the raster graphics landscape. The other part consists of the buttons, borders, illustrations, and other graphics that originate in drawing tools rather than in cameras. In the beginning of the Web, these formed the heart and soul of web graphics, and though photographs and other newer forms of graphics are making inroads in web art, we'll always need our buttons and bows.

We all envy the graphical artists their ability to create wonderful art on the Web. Barring a miraculous, sudden infusion of artistic skills, though, most of us create the graphics we need by following one of the many tutorials crafted by those who have more talent than we do.

What are some of these graphics? Pretty, shiny buttons for the forms on our web pages; reflections for text and logos to create nice banner looks; border or background images; shine or shadows to add a three-dimensional look to objects; and even text graphic headers, though we should try to restrict use of these items.

But not all raster graphics are art, nor drawn from scratch. For illustration, we incorporate the use of screen captures, hopefully with graphics to highlight whatever functionality we're trying to point out. If the tools we use for screen capturing have the ability to add highlighting functionality directly, so much the better.

Before we get into the screen capturing and button drawing, though, let's take a quick look at the building blocks for raster graphics. At the end of this chapter, I'll revisit these tools and cover how we can "reverse engineer" the graphics we find, on the Web and elsewhere, in order to figure how to create our own versions.

5.1. The Graphic Toolbox: Shapes, Layers, Gradient, and Blur

The examples and demonstrations I cover in this chapter are not all-inclusive. In fact, they barely scratch the surface of available effects you can create. The reason I selected each is to demonstrate basic graphics tool functionalities from which you can build the same or other effects. After you've had a chance to go through all of the examples, plus other example tutorials that are plentiful online, you'll get to the point where you don't need to follow a tutorial鈥攅ither you'll be able to create an effect from scratch, or you'll be able to look at an effect and "reverse engineer" how it was created just by eyeballing it.

What are these basic tool functionalities that form the basis of most online web graphics, and where can they be found in most tools?

Layers

Layers are essential in any graphics development. You can create different objects in each layer, and move them around independent of one another. Layers also allow us to add modifications to an image that we can then remove, independent of the other layers. We can use them to keep a selection active in one layer while we fill it with a gradient or solid color in another. By the time you're done with this section on raster graphics, you'll know deep in your heart that layers are your friends. Layers usually get their own top menu item in most tools.

The Gaussian Blur

The Gaussian Blur was used in the last two chapters, both to add a mood effect (Chapter 3) and to add a drop shadow to photos (Chapter 4). It continues to be an essential element in graphics creation in this chapter. Most tools provide a Gaussian Blur via whatever filter or effects top menu item the tool supports.

Rounded rectangles and other shapes

Rounded rectangles are used for buttons and badges and as building blocks for bigger works. They're usually created using the rectangular selection tool that all tools provide.

To create a rounded rectangle selection in Photoshop, draw the rectangle out using the Rectangular Marquee tool, then access Select Modify Smooth and set the radius to round the corners. Paint Shop Pro's Selection tool has a Rounded Rectangle option, but Paint.NET does not. A workaround I've used with Paint.NET is to create a rounded-corner rectangle object, then use the Magic Wand selection tool to select it.

In addition to rounded rectangles, most tools support ellipses, regular rectangles, and a variety of other shapes. You might find that different shapes are available via plug-ins rather than via the toolbar. For instance, in GIMP, to create a star or other geometrical figure, you'd select Filter Render GFig, and then create the shape in the dialog that opens.

The gradient

Most photo and graphics editing tools provide a gradient fill tool, and some provide gradient fills as attributes for objects, such as for a rectangle or an ellipse.

Layer styles

Most graphics tools provide some form of styling for the layer, including adding a drop shadow, inner glow, and so on. Photoshop's are accessible via the Layer menu (Layer Layer Style), GIMP has a Layers Script-Fu extension, and Paint Shop Pro can emulate Photoshop's layer style. Most graphics tutorials assume you have access to Photoshop-like layer styles, so searching on the tool name and the effect (such as "Paint Shop Pro inner glow") should find you the information you need to convert the effect into the tool of your choice.

There's a great Photoshop to Paint Shop Pro mapping page at http://paintshoppro.info/tutorials/photoshop_to_paintshoppro_dictionary.htm. The GIMP Layer style extension is accessible via the GIMP plug-ins.

Masks

Masks are a way of hiding or showing all of a layer and then allowing parts to be exposed or hidden, based on the color with which you're "drawing" the change. Masks are a great way of protecting part of an image, so that any edits to the layer don't affect the hidden areas. This is especially important when you're creating reflection effects or adjusting exposure or tint for only a portion of the image. Adding a mask is usually an option available directly on the layer or through the Layer menu.

Transforms

Layer transformations provide the ability to scale an image vertically, horizontally, or both; rotate an independent selection; alter perspective; or skew a layer or selection. This is most important when we're working with reflections. How each tool supports transformations varies widely. It's a tool option in the Edit menu for Photoshop, but a control toolbar item in Paint Shop Pro if a vector image has been rasterized. Do check the documentation for whatever tool you decide to use when creating these examples.

In this chapter, I decided to implement the examples using GIMP 2.4 or Photoshop. The techniques can also be used with Photoshop Elements and Paint Shop Pro, but you'll need to adapt for tool differences.

How the different functionalities get combined to form effects takes up the rest of the chapter. On with the graphics.

Chapter 5. EJB CMP

[ Team LiB ]

Chapter 5. EJB CMP Blessed are the sleepy ones: for they shall soon doze off. 桭riedrich Nietzsche, Also Sprach Zarathustra Container-managed persistence (CMP) is a persistence model in which the EJB container worries about persistence issues while you worry about business logic management. Under the CMP model, you leave most of the EJB persistence methods�A NAME="javadtabp-CHP-5-ITERM-1855"> ejbFindXXX( ), ejbLoad( ), ejbStore( ), and ejbRemove( )梕mpty. Based on a mapping you define in the application's deployment descriptor, the container implements those methods and crafts the SQL to map your beans to the database. EJB 2.0 CMP is a drastic departure from梐nd improvement upon桬JB 1.0 CMP. Nevertheless, the majority of systems in production these days are still in EJB 1.x environments. This chapter takes a look at both CMP models and describes how to use them in a production environment. As with any automated persistence mechanism, there is not a lot that EJB CMP requires you as the developer to do. The focus for this chapter is specifically on the aspects of the EJB 1.0 and EJB 2.0 CMP models that most impact persistence issues. Once you understand these concepts, you will find that you are left with almost no persistence coding to do under EJB CMP梐ll your work lies in setting up the database and writing deployment descriptors. This chapter assumes you have a basic understanding of Enterprise JavaBeans. It specifically assumes that you know the difference between entity and session beans and are familiar with home interfaces, remote interfaces, and implementation objects. If you do not have this background, you should review the Enterprise JavaBeans section of Chapter 9. I also strongly recommend the book Enterprise JavaBeans (O'Reilly) by Richard Monson-Haefel if you intend to do serious programming in an EJB environment.

[ Team LiB ]

Tape

[ Team LiB ]

Tape Tape was the first magnetic mass storage system used in computers, harking back to the days of room-size Univacs and vacuum tubes. It first proved itself as a convenient alternative to punched cards and punched paper tape梩he primary storage system used by mainframe computers. Later, information transfer became an important use for tape. Databases could be moved between systems as easily as carting around one or more spools of tape. After magnetic disks assumed the lead in primary storage, tape systems were adapted to backing them up. As a physical entity, tape is both straightforward and esoteric. It is straightforward in design, providing the perfect sequential storage medium梐 long, thin ribbon that can hold orderly sequences of information. The esoteric part involves the materials used in its construction. The tape used by any system consists of two essential layers梩he backing and the coating. The backing provides the support strength needed to hold the tape together while it is flung back and forth across the transport. Progress in the quality of the backing material mirrors developments in the plastics industry. The first tape was based on paper. Shortly after the introduction of commercial tape recorders at the beginning of the 1950s, cellulose acetate (the same plastic used in safety film in photography for three decades previously) was adopted. The state-of-the-art plastic is polyester, of double-knit leisure-suit fame. In tape, polyester has a timeless style of its own梖lexible and long-wearing with a bit of stretch. It needs all those qualities to withstand the twists and turns of today's torturous mechanisms, fast shuttle speeds, and abrupt changes of direction. The typical tape backing measures from one-quarter mil (thousandth of an inch) to one mil thick, about 10 to 40 microns. The width of the backing varies with its intended application. Wider tapes offer more area for storing data but are most costly and, after a point, become difficult to package. The narrowest tape in common use, cassette tape, measures 0.150 inches (3.8 millimeters) wide. The widest in general use for computing measures 0.5 inches (12.7 millimeters). Equipment design and storage format determine the width of tape to be used. Coatings have also evolved over the decades, as they have for all magnetic media. Where once most tapes were coated with doped magnetic oxides, modern coatings include particles of pure metal in special binders and even vapor-plated metal films. Tape coatings are governed by the same principles as other magnetic media; the form is different but the composition remains the same. As with all magnetic storage systems, modern tape media have higher coercivities and support higher storage densities. Taken by itself, tape is pretty hard to get a handle on. Pick up any reasonable length of tape, and you'll have an instant snarl on your hands. The only place that tape is used by itself is in endless loops (one end spliced to the other) in special bins used by audio and video duplicating machines. In all other applications, the tape is packaged on reels or in cartridges. Reels came first. A simple spool onto which a length of tape gets wound, the reel is the simplest possible tape carrier. In this form, tape is called open reel. Putting tape in a cartridge adds a permanent package that both provides protection to the delicate medium and makes it more convenient to load. The most basic cartridge design simply packages a reel of tape in a plastic shell and relies on an automatic threading mechanism in the drive itself. All current computer-size tape systems use a more sophisticated design梒assette-style cartridges that include both the supply and take-up reels in a single cartridge. The basic cassette mechanism simply takes the two spools of the open-reel tape transport and puts them inside a plastic shell. The shell protects the tape because the tape is always attached to both spools, eliminating the need for threading across the read/write heads and through a drive mechanism. The sides of the cassette shell serve as the sides of the tape reel梙olding the tape in place so that the center of the spool doesn't pop out. This function is augmented by a pair of Teflon slip-sheets, one on either side of the tape inside the shell, that help to eliminate the friction of the tape against the shell. A clear plastic window in either side of the shell enables you to look at how much tape is on either spool梙ow much is left to record on or play back. The reels inside the cassette are merely hubs that the tape can wrap around. A small clip that forms part of the perimeter of the hub holds the end of the tape to the hub. At various points around the inside of the shell, guides are provided to ensure that the tape travels in the correct path. More recent tape cartridges have altered some of the physical aspects of the cassette design but retain the underlying technologies. Technologies Tape systems are often described by how they work梩hat is, the way they record data onto the tape. For example, although the term streaming tape that's appended to many tape drives may conjure up images of a cassette gone awry and spewing its guts inside the dashboard of your card (and thence to the wind as you fling it out the window), it actually describes a specific recording mode that requires an uninterrupted flow of data. At least four of these terms梥tart-stop, streaming, parallel, and serpentine梒rop up in the specifications of common tape systems for computers. Start-Stop Tape The fundamental difference between tape drives is how they move the tape. Early drives operated in start-stop mode梩hey handled data one block (ranging from 128 bytes to a few kilobytes) at a time and wrote each block to the tape as it was received. Between blocks of data, the drive stopped moving the tape and awaited the next block. The drive had to prepare the tape for each block, identifying the block so that the data could be properly recovered. Watch an old movie with mainframe computers with jittering tape drives, and you'll see the physical embodiment of start-stop tape. Streaming Tape When your computer tape drive gets the data diet it needs, bytes flow to the drive in an unbroken stream and the tape runs continuously. Engineers called this mode of operation streaming tape. Drives using streaming tape technology can accept data and write it to tape at a rate limited only by the speed the medium moves and the density at which bits are packed梩he linear density of the data on the tape. Because the tape does not have to stop between blocks, the drive wastes no time. Parallel Recording Just as disk drives divide their platters into parallel tracks, the tape drive divides the tape into multiple tracks across the width of the tape. The number of tracks varies with the drive and the standard it follows. The first tape machines used with computer systems recorded nine separate data tracks across the width of the tape. The first of these machines used parallel recording, in which they spread each byte across their tracks, one bit per track, with one track for parity. A tape was good for only one pass across the read/write head, after which the tape needed to be rewound for storage. Newer tape systems elaborate on this design by laying 18 or 36 tracks across a tape, corresponding to a digital word or double word, written in parallel. Parallel recording provides a high transfer rate for a given tape speed because multiple bits get written at a time but makes data retrieval time consuming梖inding a given byte might require fast forwarding across an entire tape. Serpentine Recording Most computer tape systems use multitrack drives but do not write tracks in parallel. Instead, they convert the incoming data into serial form and write that to the tape. Serial recording across multiple tracks results in a recording method called serpentine recording. Serpentine cartridge drives write data bits sequentially across the tape in one direction on one track at a time, continuing for the length of the tape. When the drive reaches the end of the tape, it reverses the direction the tape travels and cogs its read/write head down one step to the next track. At the end of that pass, the drive repeats the process until it runs out of data or fills all the tracks. Figure 17.4 shows the layout of tracks across a tape using four tracks of serpentine recording. Figure 17.4. Layout of four tracks using serpentine recording. A serpentine tape system can access data relatively quickly by jogging its head between tracks, because it needs to scan only a fraction of the data on the tape for what you want. Additionally, it requires only a single channel of electronics and a single pole in the read/write head, thus lowering overall drive costs. Modern serpentine systems may use over 50 tracks across a tape. Helical Recording The basic principle of all the preceding tape systems is that the tape moves past a stationary head. In a helical scan recording system, both the head and tape move. Usually multiple rotating heads are mounted on a drum. The tape wraps around the drum outside its protective cartridge. Two arms pull the tape out of the cartridge and wrap it about halfway around the drum (some systems, like unlamented Betamax, wrap tape nearly all the way around the drum). So that the heads travel at an angle across the tape, the drum is canted at a slight angle, about five degrees for eight-millimeter drives and about six degrees for DAT. The result is that a helical tape has multiple parallel tracks that run diagonally across the tape instead of parallel to its edges. These tracks tend to be quite fine梥ome helical systems put nearly 2000 of them in an inch. In most helical systems, the diagonal tracks are accompanied by one or more tracks parallel to the tape edge used for storing servo control information. In video systems, one or more parallel audio tracks may also run the length of the tape. Figure 17.5 shows how the data and control tracks are arranged on a helical tape. Figure 17.5. Helical scan recording track layout. Helical scan recording can take advantage of the entire tape surface. Conventional stationary-head recording systems must leave blank areas梘uard bands梑etween the tracks containing data. Helical systems can and do overlap tracks. Although current eight-millimeter systems use guard bands, DAT writes the edges of tracks over one another. This overlapping works because the rotating head drum actually has two (or more) heads on it, and each head writes data at a different angular relationship (called the azimuth) to the tracks on the tape. In reading data, the head responds strongly to the data written at the same azimuth as the head and weakly at the other azimuth. In DAT machines, one head is skewed 20 degrees forward from perpendicular to its track; the other head is skewed backward an equal amount. Formats Each of these various recording methods, along with physical concerns such as tape width and cartridge design, allow for a nearly infinite range of tape-recording systems. When you try to make sense of backup systems, it often seems like all the possibilities have been tried in commercial products. Linear Recording Tape Systems The most straightforward tape systems use simple linear recording. That is, they move the tape past a stationary head just like the very first audio tape recorders. Linear recording is the old reliable in tape technology. The process and methods have been perfected (as much as that is possible) over more than five decades of use. Open-reel tape is still used in computer systems, but most personal computers use more modern, more compact, and more convenient cassette-style cartridges. The most common of these are patterned after a design the 3M Company first offered using quarter-inch tape as a data-recording medium. First put on the market in 1972, these initial quarter-inch cartridges were designed for telecommunications and data-acquisition applications calling for the storage of serial data, such as programming private business telephone exchanges and recording events. Compared to the cassette, the tape cartridge requires greater precision and smoother operation. To achieve that end, a new mechanical design was invented by Robert von Behren of the 3M Company, who patented it in 1971梩he quarter-inch cartridge mechanism. Instead of using the capstan drive system like cassettes, the quarter-inch cartridge operates with a belt drive system. A thin, isoelastic belt stretches throughout the cartridge mechanism, looping around (and making contact with) both the supply and take-up spools on their outer perimeters. The belt also passes around a rubber drive wheel, which contacts a capstan in the tape drive. The capstan moves the belt but is cut away with a recess that prevents it from touching the tape. The friction of the belt against the outside of the tape reels drives the tape. This system is gentler to the tape because the driving pressure is spread evenly over a large area of the tape instead of pinching the tape tightly between two rollers. In addition, it provides for smoother tape travel and packing of the tape on the spools. The tape is wound, and the guide and other parts of the mechanism arranged so that the fragile magnetic surface of the tape touches nothing but the read/write head (see Figure 17.6). Figure 17.6. Quarter-inch cartridge mechanisms (DC-600 style cartridge is shown; the DC2000 is similar but smaller). For sturdiness, the cartridge is built around an aluminum baseplate. The rest of the cartridge is transparent plastic, allowing the condition of the tape and the mechanism to be readily viewed. To try to lessen the chaos in the tape cartridge marketplace, a number of tape drive manufacturers梚ncluding DEI, Archive, Cipher Data, and Tandberg梞et together at the National Computer Conference in Houston in 1982. They decided to form a committee to develop standards so that a uniform class of products could be introduced. The organization took the name, Working Group for Quarter-Inch Cartridge Drive Compatibility, often shortened into QIC committee. In November, 1987, the organization was officially incorporated as Quarter-Inch Cartridge Standards, Inc. QIC developed a number of standards for data cartridges. But as personal computers became popular, most tape companies realized that the cartridges were just too big. Squeezing a drive to handle a six-by-four cartridge into a standard 5.25-inch drive bay is a challenge; fitting one in a modern 3.5-inch bay is impossible. Seeking a more compact medium, quarter-inch cartridge makers cut their products down to size, reducing tape capacity while preserving the proven drive mechanism. The result was the mini-cartridge. QIC quickly developed standards for the new cartridge. Because the 3M Company introduced the first mini-cartridge with the designation DC2000, many people in the computer industry persist in calling all mini-cartridges "DC2000-style" cartridges. Mini-cartridges actually come in a variety of designations. As with the current model numbers of DC600-size cartridges, the model designations of most mini-cartridges encode the cartridge capacity as their last digits. For example, a DC2080 cartridge is designed for 80MB capacity; a DC2120 for 120MB. One big advantage of the smaller cartridges is that drives for them easily fit into standard 3.5-inch bays. The mini-cartridge package measures just under 3.25x2.5x0.625 inches. As originally developed, it held 205 feet of tape with the same nominal quarter-inch width used by larger cartridges, hence the initial "2" in the designation. After trying to exploit the compact size of the mini-cartridge for years, media-makers decided they had gone too far. They cut too much capacity from their cartridges. Therefore, they added some extra inches back on the back of the cartridges so that the cartridges would still slide into smaller drives but could hold more tape. Two formats developed: Travan and QIC-EX. Travan In 1995, tape- and drive-makers pushed mini-cartridges to yet higher capacities with the simple expedient of making the cartridges bigger so that they could hold more tape. The fruit of the labors of an industry group comprising Conner, Iomega, HP, 3M Company, and Sony was called Travan technology. The increase in cartridge size appears in three dimensions. The cartridges are both wider, deeper, and taller. The added height allows the use of wider tape, the same eight-millimeter (0.315-inch) tape used by the QIC-Wide format, the format pioneered by Sony. The wider tape permits an increase in track count by about 30 percent (from 28 to 36 in the initial Travan format). In addition, Travan adds an extra half-inch to the width and depth of cartridges. The Travan cartridge measures 0.5x3.6x2.8 inches (HWD), smaller in the front (3.2 inches) than the rear, where the tape spools reside. Internally, the Travan cartridge uses the same 3M mechanism as other quarter-inch cartridges and must be formatted before use. Although the increase seems modest, it allows the tape capacity to more than double, from 307 feet in a DC2120 cartridge to 750 feet in the Travan. The extra size gives Travan a distinctive shape, basically rectangular with two corners curved in to make sliding in a cartridge easier. Figure 17.7 shows a Travan cartridge. Figure 17.7. A Travan tape cartridge. The combination of more tracks and greater tape length was sufficient to boost single cartridge capacity to 400MB (uncompressed) in the initial Travan implementation. Nothing about the Travan design impairs making further improvements, so whatever developments add to the capacity of standard mini-cartridges can be directly reflected in increased Travan capacities. In fact, since its introduction, Travan has been improved three times, each change about doubling single-cartridge capacities. The first change, creating TR-2, boosted the coercivity of the medium and allowed for a 50-percent increase in data density, both in a greater number of tracks and a higher linear density on each track. The next change doubled linear density again, without altering the track count, to create TR-3. Another increase in linear density and matching increase in track count boosted the TR-4 Travan implementation to 4GB per cartridge. Table 17.7 summarizes the characteristics of the various Travan implementations. Table 17.7. Travan Tape Cartridge Specifications Model TR-1 TR-2 TR-3 TR-4 Capacity, uncompressed 400MB 800MB 1.6GB 4GB Capacity, compressed 800MB 1.6GB 3.2GB 8GB Minimum transfer rate 62.5KBps 62.5KBps 125KBps 567KBps Maximum transfer rate 125KBps 125KBps 250KBps 567KBps Media length 750 ft. 750 ft. 750 ft. 740 ft. Media width 0.315 in. 0.315 in. 0.315 in. 0.315 in. Media coercivity 550 Oe 900 Oe 900 Oe 900 Oe Tracks 36 50 50 72 Data density 14,700 ftpi 22,125 ftpi 44,250 ftpi 50,800 ftpi Interface Floppy Floppy Floppy SCSI/E-IDE Read/write compatibility QIC-80 QIC-3010 3020/3010 3080/3095 Read-only compatibility QIC-40 QIC-80 QIC-80 QIC-3020 Perhaps the most notable part of the Travan design is its compatibility: A Travan drive accepts standard DC2000 cartridges and QIC-Wide cartridges as well as its own native media梩hat's two different cartridge sizes and tape widths in one drive. Compatibility extends to both reading and writing all three cartridge styles. The various Travan implementations also feature backward compatibility. The more recent standards can read tapes made under the earlier Travan standards. QIC-EX As long as the cartridge in a QIC drive sticks out like Travan, you might as well let it all hang out. That dated cliché underlies the philosophy of QIC-EX. By allowing a cartridge to stick nearly three inches out of the drive, QIC-EX accommodates up to 1000 feet of tape in the QIC format. That's more than double the capacity of ordinary mini-cartridges. Increase the tape width to QIC-Wide's eight millimeters, and you can fit gigabytes onto a standard tape cartridge, as shown in Figure 17.8. Figure 17.8. Dimensions of a QIC-EX tape cartridge. Unlike Travan, which requires a wider drive with a wider throat to accommodate the wider cartridges, the QIC-EX design is the same width as standard mini-cartridges. QIC-EX tapes consequently fit into most mini-cartridge drives to give an instant capacity increase. Helical-Scan Systems Although helical-scan recording was originally designed for video signals, it is also an excellent match for digital data. The high tape-to-head speed can translate to high data-transfer rates. Although the narrow data tracks devote but a small area of recording medium to storing information, so small that it increases the noise content of the recorded signal, digital technology handily avoids the noise. As with all digital signals, the electronics of the helical-scan tape system simply ignore most of the noise, and error correction takes care of anything that can't be ignored. Helical-scan systems are the children of the digital age. They trade the mechanical precision required in the linear-scan systems for servo-controlled designs. Servo-mechanisms in the helical-scan recorder control both the tape speed and head speed to ensure that the read/write head exactly tracks the position of the tracks on the tape. Although servo-electronics can be built with other technologies, digital electronics and miniaturization make the required circuitry trivial, a single control chip. Moreover, servo-control automatically compensates for inaccuracies in the operation and even construction of the tape-transport system. This design allows manufacturers to use less expensive fabrication processes and helps the mechanism age gracefully, adjusting itself for the wear and tear of old age. Three different helical-scan systems are currently used in tape systems for digital data: eight-millimeter tape, four-millimeter tape (which is formally called the Digital Data Standard), and a proprietary system sold by Pereos. Eight Millimeter Probably the most familiar incarnation of eight-millimeter tape is in miniaturized camcorders. Sony pioneered the medium as a compact, high-quality video-recording system. The same tapes were later adapted to data recording by Exabyte Corporation and first released on the computer market in 1987. In the original Exabyte eight-millimeter digital recording system, the head drum rotated at 1800 revolutions per minute while the tape traveled past it at 10.89 millimeters per second to achieve a track density of 819 per inch and a flux density of 54 kilobits per inch梕nough to squeeze 2.5MB on a single cartridge. Improvements extended the capacity to 5MB without compression and up to 10GB with compression. The tape can be rapidly shuttled forward and backward to find any given location (and block of data) within about 15 seconds. Eight-millimeter drives tend to be quite expensive. Complete systems cost thousands of dollars. A raw drive alone starts at over one thousand dollars. Its primary market is backing up file servers, machines that can benefit from its huge capacity. Advanced Intelligent Tape Sony developed an alternative eight-millimeter technology. By incorporating nonvolatile RAM memory into the shell of an eight-millimeter tape, a tape drive can quickly retrieve directory information without the need to scan the tape. It doesn't have to read the tape at all to find out what's there. This memory is what makes Sony's Advanced Intelligent Tape so smart. Each cartridge has 16KB for storing table of contents and file-location information. Each cartridge can store 25MB of uncompressed data. With data compression the AIT system can achieve transfer rates of 6MBps and a capacity of 50MB per cartridge. Despite being based on eight-millimeter technology, AIT is not backward compatible with the older medium. AIT drives reject conventional eight-millimeter tapes as unsupported media, and hardware write-protection prevents older drives from altering AIT tapes. Digital Data Storage Developed originally as a means to record music, the Digital Data Storage first saw commercial application as Digital Audio Tape (DAT), a name sometimes applied to the system even when it is used for storing computer data. The technology was first released as a computer storage medium in 1989. Using a tape that's nominally four millimeters wide (actually 3.81 mm or 0.150 in, the same as cassette tape), the system is sometimes called four-millimeter tape. The thin tape fits into tiny cartridges to store huge amounts of data. The first DAT system could pack 1.3GB into a cassette measuring only 0.4 x 2.9 x 2.1 inches (HWD). The result was, at the time, the most dense storage of any current computer tape medium, 114 megabits per square inch on special 1450 oersted metal particle tape (the same material as used by eight-millimeter digital tape systems). A cassette held either 60 or 90 meters of this tape. The shorter tapes stored 1.3GB; the longer tapes, 2.0GB. Under the aegis of Hewlett-Packard and Sony Corporation, in 1990 this format was formalized as DDS, sometimes listed as DDS-1 (to distinguish it from its successors). The same format underlies DDS-DC, which adds data compression to the drive to increase capacity. Although DDS at first was listed in some literature (and in an earlier edition of this book) as an abbreviation for Digital Data Standard, the DDS organization that coordinates the specification renders it officially as Digital Data Storage. In 1993, the same companies updated the standard to DDS-2, doubling both the data-transfer speed and capacity of the system as well as introducing new 120-meter cassettes using a tape coated with a metal powder medium. In 1995, the standard got upped again to DDS-3, which can pack up to 12GB on each cartridge or 24GB of compressed data. In addition, the DDS-3 standard allows for transfers at double the DDS-2 rate with speed potential of up to 1.5 megabits per second (discounting the effects of compression). DDS-3 uses the same tape media as its predecessor format but increases the data density to 122 kilobits per inch. The key to this higher density is a new technology termed Partial Response Maximum Likelihood (PRML). Announced in 1998, DDS-4 further enhances the four-millimeter format to provide 20GB of storage on a single tape. Part of the capacity increase results from longer tapes, up to 155 meters per cartridge. In addition, DDS-4 reduces track width by 25 percent. Because of its higher data density, DDS-4 also gains a bit of speed. The standard allows for transfer rates from 1 to 3Mbps. DDS-5, originally planned for the year 2001, aimed for a native capacity of 40GB per cartridge but has yet to be formally released. The DDS Web site has not been updated since 1999. Table 17.8 summarizes the various DDS implementations. Table 17.8. Summary of DDS Specifications Format DDS DDS-DC DDS-2 DDS-3 DDS-4 DDS-5 Year introduced 1989 1991 1993 1995 1999 2001 Cartridge capacity 1.3GB 2.0GB 4.0GB 12GB 20GB 40GB Transfer rate 183Kbps 183Kbps 360 to 750Kbps 720Kbps to 1.5Mbps 1 to 3Mbps 1 to 6Mbps Tape length 60 m 90 m 120 m 125 m 155 m N/A In a DDS drive, the tape barely creeps along, requiring about three seconds to move an inch梐 tape speed of 8 millimeters per second. The head drum, however, spins rapidly at 2000 revolutions per minute, putting down 1869 tracks across a linear inch of tape with flux transitions packed 61 kilobits per inch. The first DAT systems shared tapes with audio DAT recorders. Since that time, however, the later DDS standards have required improved magnetic media with higher coercivities. As a result, to get the highest reliability you must use a tape made to the standard that matches your drive. Although you may be able to read older tapes in a later DDS drive, successful writing (where coercivity comes into play) is less probable. Similarly, DDS tape will not work in your DAT recorder. The DDS Manufacturers Group, the organization that coordinates DDS activities, has also developed a technology called Media Recognition System that is able to detect audio DAT tapes. The DDS organization has developed distinctive logos for each level of the DDS hierarchy so that you can readily distinguish tapes and drives. Figure 17.9 shows the logos for DDS-2 through DDS-4. Figure 17.9. The official DDS-2, DDS-3, and DDS-4 logos. Hewlett-Packard and Sony hold intellectual property rights to DDS technology, and all drives using DDS must be licensed by them. The DDS Manufacturers Group maintains a Web site at www.dds-tape.com. Alas, all tape technologies have lost their luster. They are all hard-pressed to keep up with the huge increases in disk storage densities and capacities. The tape systems with adequate capacity for backing up today's hard disk drives cost more than most personal computers. Consequently, most individual users prefer other backup methods, such as extra hard disks, networked storage (including backing up over the Internet), DVD recorders, and simply ignoring the need for backing up. Data centers rely on a few super-capacity backup systems that are priced well beyond the reach of individuals. Tape is therefore not quite dead. You can use either a mini-cartridge or DDS system for backing up a few gigabytes (about 20GB without compression with today's drives). That should be sufficient for keeping a spare copy of your personal files (including such megabyte-hogs as Computer-Aided Design drawings, graphics, and videos). However, DVD is probably the best, lowest-cost bet for backup today.

[ Team LiB ]