Software Information

What is a Software Engineer?

A software are engineer is in charge of assembling extensive amounts of code into working applications, as well as updating and fixing problems in existing software. A software engineer is also referred to as a programmer, because the main duties of a software engineer involve programming computers. Software engineering may be compared with computer science. While a software engineer works on actually developing working software solutions, a computer scientist focuses on the theoretical construct of software and hardware development.

There is some debate over whether a software engineer should rather be referred to as a developer or programmer, because of connotations held by the term engineer. Many charge that software development is not held to the same rigorous and exacting standards as fields such as electrical engineering, and therefore should not be associated with other, more strict forms of engineering. The title of software engineer, as a result of these controversies, is bestowed rather haphazardly. The industry itself has not yet come up with widely agreed upon practices for licensing software engineers —- something other engineering disciplines have —- and so even a person without formal training may be referred to as a software engineer.

There are estimated to be over two-and-a-half million software engineers worldwide, a number less than, but rapidly approaching, that of traditional engineers. The role of software engineers in society is expanding as computers and their applications become more pervasive. Economically, socially and politically, computers are changing the world everywhere they reach, and software engineers are building the tools that drive that change.

Only about one-half of software engineers in the industry hold a degree of some level in computer science, and less than five percent hold a degree specifically in software engineering. These numbers are growing, as the marketplace becomes more competitive and entry-level software engineers struggle to distinguish themselves. A number of graduate programs exist for both computer science and software engineering, as well, though these degrees are often acquired after some years of experience in the field.

Ultimately, what a software engineer is and what their specific jobs are is open to some debate. It is clear that they play an integral part in the development of software applications for computer systems, integrating not just programming skills but also design and conceptual skills as well. Some may build database structures, while others may work on the embedded software necessary to make electronic devices function, and still others may write games and consumer-level applications. Whatever the specific role of an individual software engineer, the fundamental job of generating code to help a computer act or react stays the same.

What is a software architecture?

This introduction to the relatively new discipline of software architecture is the first of a four-part series on "architecting" in general. The author begins by defining the discipline's key terms and goes on to explore what a well-designed architecture contributes to the environment in which it is deployed.

There is no doubt that the world is becoming increasingly dependent on software. Software is an essential element of the ubiquitous cell phone, as well as complex air traffic control systems. In fact, many of the innovations that we now take for granted -- including organizations such as eBay or Amazon -- simply wouldn't exist if it weren't for software. Even traditional organizations, such as those found in the finance, retail, and public sectors, depend heavily on software. In this day and age, it's difficult to find an organization that isn't, in some way, in the software business.

In order for such innovations and organizations to survive, the software they depend on must provide the required capability, be of sufficient quality, be available when promised, and be delivered at an acceptable price.

All these characteristics are influenced by the architecture of the software, the subject of this article. My focus here is on "software-intensive systems," which the IEEE defines as follows:

A software-intensive system is any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole. [from IEEE 1471. See the "Architecture defined" section below.]

In this article, the term "architecture," when unqualified, is synonymous with the term "software architecture." Although this article focuses on software-intensive systems, it is important to remember that a software-intensive system still needs hardware in order to execute and that certain qualities, such as reliability or performance, are achieved through a combination of software and hardware. The hardware aspect of the total solution cannot therefore be ignored. This is discussed in more detail later in this article.

Architecture defined

There is no shortage of definitions when it comes to "architecture." There are even Websites that maintain collections of definitions.¹ The definition used in this article is that taken from IEEE Std 1472000, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, referred to as IEEE 1471.² This definition follows, with key characteristics bolded.

Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]

This standard also defines the following terms related to this definition:

A system is a collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. A system exists to fulfill one or more missions in its environment. [IEEE 1471]

The environment, or context, determines the setting and circumstances of developmental, operational, political, and other influences upon that system. [IEEE 1471]

A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. [IEEE 1471]

A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. [IEEE 1471]

As we can see, the term "component" is used throughout these definitions. However, most definitions of architecture do not define the term "component," and IEEE 1471 is no exception, as it leaves it deliberately vague to cover the many interpretations in the industry. A component may be logical or physical, technology-independent or technology-specific, large-grained or small-grained. For the purposes of this article, I use the definition of component from the UML 2.0 specification; and I use the term fairly loosely in order to encompass the variety of architectural elements that we may encounter, including objects, technology components (such as an Enterprise JavaBean), services, program modules, legacy systems, packaged applications, and so on. Here is the UML 2.0 definition for "component":

[A component is] a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics).³

The definitions provided here cover a number of different concepts, which are discussed in more detail later in this article. Although there is no generally agreed definition of "architecture" in the industry, it is worth considering some other definitions so that similarities between them can be observed. Consider the following definitions where, again, I've bolded some of the key characteristics.

An architecture is the set of significant decisions about the organization of a software system, the selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these elements into progressively larger subsystems, and the architectural style that guides this organization -- these elements and their interfaces, their collaborations, and their composition. [Kruchten]⁴

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. [Bass et al.]⁵

[Architecture is] the organizational structure and associated behavior of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems. [UML 1.5]⁶

The software architecture of a system or a collection of systems consists of all the important design decisions about the software structures and the interactions between those structures that comprise the systems. The design decisions support a desired set of qualities that the system should support to be successful. The design decisions provide a conceptual basis for system development, support, and maintenance. [McGovern]⁷

Although the definitions are somewhat different, we can see a large degree of commonality. For example, most definitions indicate that an architecture is concerned with both structure and behavior, is concerned with significant decisions only, may conform to an architectural style, is influenced by its stakeholders and its environment, and embodies decisions based on rationale. All of these themes, and others, are discussed below.

An architecture defines structure

If you were to ask anyone to describe "architecture" to you, nine times out of ten, they'll make some reference to structure. This is quite often in relation to a building or some other civil engineering structure, such as a bridge. Although other characteristics of these items exist, such as behavior, fitness-for-purpose, and even aesthetics, it is the structural characteristic that is the most familiar and the most-often mentioned.

It should not surprise you then that if you ask someone to describe the architecture of a software system he's working on, you'll probably be shown a diagram that shows the structural aspects of the system -- whether these aspects are architectural layers, components, or distribution nodes. Structure is indeed an essential characteristic of an architecture. The structural aspects of an architecture manifest themselves in many ways, and most definitions of architecture are deliberately vague as a result. A structural element can be a subsystem, a process, a library, a database, a computational node, a legacy system, an off-the-shelf product, and so on.

Many definitions of architecture also acknowledge not only the structural elements themselves, but also the composition of structural elements, their relationships (and any connectors needed to support these relationships), their interfaces, and their partitioning. Again, each of these elements can be provided in a variety of ways. For example, a connector could be a socket, be synchronous or asynchronous, be associated with a particular protocol, and so on.

An example of some structural elements is shown in Figure 1. This figure shows a UML class diagram containing some structural elements that represent an order processing system. Here we see three classes -- OrderEntry, CustomerManagement, and AccountManagement. The OrderEntry class is shown as depending on the CustomerManagement class and also the AccountManagement class.

Figure 1: UML class diagram showing structural elements

An architecture defines behavior

As well as defining structural elements, an architecture defines the interactions between these structural elements. It is these interactions that provide the desired system behavior. Figure 2 shows a UML sequence diagram showing a number of interactions that, together, allow the system to support the creation of an order in an order processing system. Here we see five interactions. First, a Sales Clerk actor creates an order using an instance of the OrderEntry class. The OrderEntry instance gets customer details using an instance of the CustomerManagement class. The OrderEntry instance then uses an instance of the AccountManagement class to create the order, populate the order with order items, and then place the order.

Figure 2: UML sequence diagram showing behavioral elements

It should be noted that Figure 2 is consistent with Figure 1 in that we can derive the dependencies shown in Figure 1 from the interactions defined in Figure 2. For example, an instance of OrderEntry depends on an instance of CustomerManagement during its execution, as shown by the interactions in Figure 2. This dependency is reflected in a dependency relationship between the corresponding OrderEntry and CustomerManagement classes, as shown in Figure 1.

An architecture focuses on significant elements

While an architecture defines structure and behavior, it is not concerned with defining all of the structure and all of the behavior. It is only concerned with those elements that are deemed to be significant. Significant elements are those that have a long and lasting effect, such as the major structural elements, those elements associated with essential behavior, and those elements that address significant qualities such as reliability and scalability. In general, the architecture is not concerned with the fine-grained details of these elements. Architectural significance can also be phrased as economical significance, since the primary driver for considering certain elements over others is the cost of creation and cost of change.

Since an architecture focuses on significant elements only, it provides us with a particular perspective of the system under consideration -- the perspective that is most relevant to the architect.⁸ In this sense, an architecture is an abstraction of the system that helps an architect manage complexity.

It is also worth noting that the set of significant elements is not static and may change over time. As a consequence of requirements being refined, risks identified, executable software built, and lessons learned, the set of significant elements may change. However, the relative stability of the architecture in the face of change is, to some extent, the sign of a good architecture, the sign of a well-executed architecting process, and the sign of a good architect. If the architecture needs to be continually revised due to relatively minor changes, then this is not a good sign. However, if the architecture is relatively stable, then the converse is true.

An architecture balances stakeholder needs

An architecture is created to ultimately address a set of stakeholder needs. However, it is often not possible to meet all of the needs expressed. For example, a stakeholder may ask for some functionality within a specified timeframe, but these two needs (functionality and timeframe) are mutually exclusive. Either the scope can be reduced in order to meet the schedule or all of the functionality can be provided within an extended timeframe. Similarly, different stakeholders may express conflicting needs and, again, an appropriate balance must be achieved. Making tradeoffs is therefore an essential aspect of the architecting process, and negotiation, an essential characteristic of the architect.

Just to give you an idea of the task at hand, consider the following needs of a set of stakeholders:

• The end user is concerned with intuitive and correct behavior, performance, reliability, usability, availability, and security.
• The system administrator is concerned with intuitive behavior, administration, and tools to aid monitoring.
• The marketer is concerned with competitive features, time to market, positioning with other products, and cost.
• The customer is concerned with cost, stability, and schedule.
• The developer is concerned with clear requirements, and a simple and consistent design approach.
• The project manager is concerned with predictability in the tracking of the project, schedule, productive use of resources, and budget.
• The maintainer is concerned with a comprehensible, consistent, and documented design approach, and the ease with which modifications can be made.

As we can see from this list, another challenge for the architect is that the stakeholders are not only concerned that the system provides the required functionality. Many of the concerns listed are nonfunctional in nature in that they do not contribute to the functionality of the system (e.g., the concerns regarding costs and scheduling). Such concerns nevertheless represent system qualities or constraints. Nonfunctional requirements are quite often the most significant requirements as far as an architect is concerned.

An architecture embodies decisions based on rationale

An important aspect of an architecture is not just the end result, the architecture itself, but the rationale for why it is the way it is. Thus, an important consideration is to ensure that you document the decisions that have led to this architecture and the rationale for those decisions.

This information is relevant to many stakeholders, especially those who must maintain the system. This information is often valuable to the architect when he or she needs to revisit the rationale behind the decisions that were made, so that they don't end up having to unnecessarily retrace steps. For example, this information is used when the architecture is reviewed and the architect needs to justify the decisions that have been made.

An architecture may conform to an architectural style

Most architectures are derived from systems that share a similar set of concerns. This similarity can be described as an architectural style, which can be thought of as a particular kind of pattern, albeit an often complex and composite pattern (a number of patterns applied together). Like a pattern, an architectural style represents a codification of experience, and it is good practice for architects to look for opportunities to reuse such experience. Examples of architectural styles include a distributed style, a pipe-and-filter style, a data-centered style, a rule-based style, and so on. A given system may exhibit more than one architectural style. As Shaw and Garlan describe it:

[An architectural style] defines a family of systems in terms of a pattern of structural organization. More specifically, an architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined.⁹

And in terms of the UML:

[A pattern is] a common solution to a common problem in a given context.¹⁰

In addition to reusing experience, the application of an architectural style (or a pattern) makes our lives as architects somewhat easier, since a style is normally documented in terms of the rationale for using it (and so there is less thinking to be done) and in terms of its structure and behavior (and so there is less architecture documentation to be produced since we can simply refer to the style instead).

An architecture is influenced by its environment

A system resides in an environment, and this environment influences the architecture. This is sometimes referred to as "architecture in context." In essence, the environment determines the boundaries within which the system must operate, which then influence the architecture. The environmental factors that influence the architecture include the business mission that the architecture will support, the system stakeholders, internal technical constraints (such as the requirement to conform to organizational standards), and external technical constraints (such as the need to interface to an external system or to conform to external regulatory standards).

Conversely, as eloquently described in Bass, Clements, and Kazman,¹¹ the architecture may also influence its environment. Not only does the creation of an architecture change the environment from a technology perspective -- it may, for example, contribute reusable assets to the owning organization -- the creation of the architecture may also change the environment in terms of the skills available within the organization.

When it comes to software-intensive systems, there is a particular aspect of the environment that must always be considered, as discussed earlier in this chapter. In order for software to be useful, it must execute. In order to execute, the software runs on some kind of hardware. The resulting system is therefore a combination of both software and hardware, and it is this combination that allows properties such as reliability and performance to be achieved. Software cannot achieve these properties in isolation of the hardware on which it executes.

IEEE Std 12207-1995, the IEEE Standard for Information Technology -- Software Life Cycle Processes, defines a system differently from the IEEE 1471 system definition noted earlier (which focuses on software-intensive systems), but is in agreement with the definitions found in the systems engineering field:

[A system is] an integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. [IEEE 12207]¹²

A configuration of the Rational Unified Process for Systems Engineering (RUP SE) contains a similar definition.

[A system is] a set of resources that provide services that are used by an enterprise to carry out a business purpose or mission. System components typically consist of hardware, software, data, and workers¹³.

In the systems engineering field, tradeoffs are made regarding the use of software, hardware, and people. For example, if performance is key, then a decision may be made to implement certain system elements in hardware, rather than software or people. Another example is that in order to provide a usable system to customers, a decision is made to provide a customer interface that is a human being, rather than an interface implemented in software or hardware. More complex scenarios require certain system qualities to be achieved through a combination of software, hardware, and people. (Accordingly, this series of articles makes reference to elements other than software where appropriate.)

It is interesting to note that systems engineering is specifically concerned with treating software and hardware (as well as people) as peers, thus avoiding the pitfall where hardware is treated as a second-class citizen to the software and is simply a vehicle for executing the software, or where software is treated as a second-class citizen with respect to the hardware and is simply a vehicle for making the hardware function as desired.

An architecture influences team structure

An architecture defines coherent groupings of related elements that address a given set of concerns. For example, an architecture for an order processing system may have defined groupings of elements for order entry, account management, customer management, fulfillment, integrations with external systems, persistency, and security.

Each of these groupings may require different skill sets. It therefore makes perfect sense to align software development team structures with the architecture once it has been defined. However, it is often the case that the architecture is influenced by the initial team structure and not vice versa. This is a pitfall that is best avoided, since the result is typically a less-than-ideal architecture. "Conway's Law" states that "If you have four groups working on a compiler, you'll get a 4-pass compiler." In practice, we often unintentionally create architectures that reflect the organization creating the architecture.

However, it is also true to say that this somewhat idealized view is not always practical since, for purely pragmatic reasons, the current team structure and the skills available represent a very real constraint on what is possible and the architect must take this into account.

An architecture is present in every system

It is also worth noting that every system has an architecture, even if this architecture is not formally documented or if the system is extremely simple and, say, consists of a single element. There is usually considerable value in documenting the architecture. Documented architectures tend to be more carefully considered -- and therefore, more effective -- than those that are not, since the process of recording the architecture naturally leads to thoughtful consideration.

Conversely, if an architecture is not documented, then it is difficult (if not impossible) to prove that it meets the stated requirements in terms of addressing qualities such as maintainability, accommodation of best practices, and so on. Architectures that are not documented, which appear to be the majority in existence today, tend to be accidental rather than intentional.

An architecture has a particular scope

There are many kinds of architecture, the best known being the architecture associated with buildings and other civil engineering structures. Even in the field of software engineering, we often come across different forms of architecture. For example, in addition to the concept of software architecture, we may encounter concepts such as enterprise architecture, system architecture, organizational architecture, information architecture, hardware architecture, application architecture, infrastructure architecture, and so on. You will also hear other terms, each of which defines a specific scope of the architecting activities.

Unfortunately, there is no agreement in the industry on the meaning of each of these terms or their relationship to one another, which results in different meanings for the same term (homonyms) and two or more terms meaning the same thing (synonyms). However, the scope of some of these terms can be inferred from Figure 3. As you consider this figure and the discussion that follows, there are almost certainly elements of it that you disagree with or that you use differently within your organization. But that is exactly the point -- to show that these terms do exist in the industry, but that there is no consensus on their meaning.

Figure 3: The scope of different terms

The elements shown in Figure 3 are:

• Software architecture, which is the main focus of this article as defined earlier.
• A hardware architecture, which considers elements such as CPUs, memory, hard disks, peripheral devices such as printers, and the elements used to connect these elements.
• An organizational architecture, which considers elements that are concerned with business processes, organizational structures, roles and responsibilities, and core competencies of the organization.
• An information architecture, which considers the structure by which information is organized.
• Software architecture, hardware architecture, organizational architecture, and information architecture, which are all subsets of the overall system architecture, as discussed earlier in this chapter.
• An enterprise architecture, which is similar to a system architecture in that it, too, considers elements such as hardware, software, and people. However, an enterprise architecture has a stronger link to the business in that it focuses on the attainment of the business objectives and is concerned with items such as business agility and organizational efficiency. An enterprise architecture may cross company boundaries.

As one would expect, there are corresponding forms of architect (for example, software architect, hardware architect, and so on) and architecting (for example, software architecting, hardware architecting, and so on).

Now that we've gotten through these definitions, there are many unanswered questions. What is the difference between an enterprise architecture and a system architecture? Is an enterprise a system? Is an information architecture the same as the data architecture found in some data-intensive software applications? Unfortunately, there is no set of agreed-upon answers to these questions.

For now, you should simply be aware that these different terms exist, but that there is no consistent definition of these terms in the industry and how they relate. The recommendation, therefore, is for you to select the terms relevant to your organization and define them appropriately. You will then achieve some consistency at least and reduce the potential for miscommunication.

Summary

This article has focused on defining the core characteristics of a software architecture. However, there are many questions left unanswered. What is the role of the software architect? What are the key activities that the architect is involved in? What are the benefits of "architecting"? These questions, and others, will be answered in subsequent articles in this series.

Acknowledgements

The contents of this article have been derived from a forthcoming book, provisionally entitled "The Process of Software Architecting." As a result, the content has been commented upon by many individuals that I would like to thank, who are Grady Booch, Dave Braines, Alan Brown, Mark Dickson, Holger Heuss, Kelli Houston, Luan Doan-Minh, Philippe Kruchten, Nick Rozanski, Dave Williams, and Eoin Woods.

INTRODUCTION TO AUTOCAD 2006

Description
Taking the reader step by step through the features of AutoCAD, Alf Yarwood provides a practical, structured course of work matched to the latest release of this software. Introducing first principles and the creation of 2D technical drawings, the author goes on to demonstrate construction of 3D solid model drawings and rendering of 3D models – in particular, DYN (dynamic input showing coordinate position and lengths – an important new feature of the latest AutoCAD software), and new commands in the Modify and Dimension tool sets are introduced. Other enhancements found with AutoCAD 2006 are also covered in detail. Worked examples and exercises are included throughout the text, to enable the reader to apply theory into real-world engineering practice, along with revision notes and exercises at the end of chapters for the reader to check their understanding of the material they have covered. Introduction to AutoCAD 2006 contains hundreds of drawings and screen-shots to illustrate the stages within the design process. Readers can also visit a companion website and make use of a full colour AutoCAD Gallery, where they can modify drawings from the exercises found within the text, and see solutions to all exercises featured in the book. Further exercises in 3D work are also available to download. Details of enhancements to AutoCAD 2006 over previous releases are given in the text, along with illustration of how AutoCAD fits into the design process as a whole. Appendices with full glossaries of tools and abbreviations, most frequently used set variables, and general computer terms are also included. Suitable to new users of AutoCAD, or anyone wishing to update their knowledge from previous releases of the software, this book is also applicable to introductory level undergraduate courses and vocational courses in engineering and construction.

Audience
First year undergraduate engineering, construction and architecture students, all using CAD. Students taking vocational courses in engineering drawing and design (mechanical engineering and manufacturing). Professional engineers learning AutoCAD for the first time, or any user wishing to update their knowledge from earlier versions of AutoCAD.

Contents
Preface. Registered Trademarks.

1 Introducing AutoCAD 2006:
Aim of this chapter. Opening AutoCAD 2006. The mouse as a digitiser. Palettes . Toolbars. Dialogs. Buttons in the status bar. The AutoCAD coordinate system. Drawing templates. Method of showing entries in the command palette. Tools and tool icons. Revision notes.

2 Introducing drawing:
Aims of this chapter. Drawing with the Line tool. Drawing with the Circle tool. The Erase tool. Undo and Redo tools. Drawing with the Polyline tool. Revision notes. Exercises.

3 Osnap, AutoSnap and Draw tools:
Aims of this chapter. Introduction. The Arc tool. The Ellipse tool. Saving drawings. Osnap, AutoSnap and Dynamic Input. Object Snaps (Osnaps). AutoSnap. Dynamic Input. Examples of using some Draw tools. The Polyline Edit tool. Transparent commands. The set variable PELLIPSE. Revision notes. Exercises.

4 Zoom, Pan and templates:
Aims of this chapter. Introduction. The Aerial View window. The Pan tool. Drawing templates. Revision notes.

5 The Modify tools:
Aim of this chapter. Introduction. The Copy tool. The Mirror tool. The Offset tool. The Array tool. The Move tool. The Rotate tool. The Scale tool. The Trim tool. The Stretch tool. The Break tool. The Join tool. The Extend tool. The Chamfer and Fillet tools. Selection windows. Revision notes. Exercises.

6 Dimensions and Text:
Aims of this chapter. Introduction . The Dimension tools. Adding dimensions using the tools. Adding dimensions from the command line. Dimension tolerances. Text. Symbols used in text. Checking spelling. Revision notes . Exercises .

7 Orthographic and isometric:
Aim of this chapter. Orthographic projection. First angle and third angle. Sectional views. Isometric drawing. Examples of isometric drawings. Revision notes. Exercises.

8 Hatching:
Aim of this chapter. Introduction. Revision notes. Exercises.

9 Blocks and Inserts:
Aims of this chapter. Introduction. Blocks. Inserting blocks into a drawing. The Explode and Purge tools. Wblocks. Revision notes. Exercises.

10 Other types of file format:
Aims of this chapter. Object linking and embedding. DXF (Data Exchange Format) files. Raster images. External References (Xrefs). Multiple Document Environment (MDE. Revision notes. Exercises.

11 Sheet sets:
Aims of this chapter. Sheet sets. Revision notes. Exercises.

12 Building drawing:
Aim of this chapter. Building drawings. Floor layouts. Revision notes. Exercises.

13 Introducing 3D modelling:
Aims of this chapter. Introduction. The toolbars containing Solid and Render tools. Examples of 3D drawings using the 3D Face tool. 2D outlines suitable for 3D models. The Extrude tool. Examples of the use of the Extrude tool. The Revolve tool. Examples of the use of the Revolve tool. 3D objects. The Chamfer and Fillet tools. Note on the tools Union, Subtract and Intersect. Note on using Modify tools on 3D models. Note on rendering. Revision notes. Exercises.

14 3D models in viewports:
Aim of this chapter. Setting up viewport systems. Revision notes. Exercises.

15 The modification of 3D models:
Aims of this chapter. Creating 3D model libraries. The 3D Array tool. The Mirror 3D tool. The Rotate 3D tool. The Slice tool. The Section tool. The Massprop tool. Views of 3D models. Revision notes. Exercises.

16 Rendering:
Aims of this chapter. The Render tools. The 3D Orbit toolbar. Producing hardcopy. Saving and opening 3D model drawings. Exercises.

17 Three-dimensional space:
Aim of this chapter. 3D space. The User Coordinate System (UCS). The variable UCSFOLLOW. The UCS icon. Examples of changing planes using the UCS. Saving UCS views. Constructing 2D objects in 3D space. Revision notes. Exercises.

18 3D Surface models:
Aims of this chapter. 3D surface meshes. Comparisons between Solids and Surfaces tools. The Surface tools. The action of Pedit on a 3D surface. Notes on the 3D Surface tools. Rendering of 3D Surface models. Revision notes. Exercises.

19 Editing 3D solid models: More 3D models:
Aims of this chapter. The Solids Editing tools. Examples of more 3D models. Exercises.

20 Other features of 3D modelling:
Aims of this chapter. Raster images in AutoCAD drawings. The Profile tool. Printing/Plotting. Polygonal viewports. Exercises.

21 Internet tools:
Aim of this chapter. Emailing drawings. Example – creating a web page. Browsing the Web. The eTransmit tool.

22 Design and AutoCAD 2006:
Ten reasons for using AutoCAD. The place of AutoCAD 2006 in designing. Enhancements in AutoCAD 2006. System requirements for running AutoCAD 2006.

Appendix A Printing/Plotting:
Introduction. An example of a printout.

Appendix B List of tools:
Introduction. 2D tools. 3D tools. Internet tools.

Appendix C Some of the set variables:
Introduction. Some of the set variables.

Appendix D Computing terms.
Index.

Bibliographic & ordering Information
Paperback, 352 pages, publication date: DEC-2005
ISBN-13: 978-0-7506-6876-7
ISBN-10: 0-7506-6876-8
Imprint: NEWNES
Price:
GBP 20.99
USD 38.95
EUR 30.95

Books and book related electronic products are priced in US dollars (USD), euro (EUR), and Great Britain Pounds (GBP). USD prices apply to the Americas and Asia Pacific. EUR prices apply in Europe and the Middle East. GBP prices apply to the UK and all other countries.

New Software - Usability / Web Consulting
New Software, Inc. was founded by Vadim Akselrod, a user interface specialist
who has been addressing usability issues since 1987. New Software, Inc. specializes
in bringing new, innovative, and usable interfaces to the on-line community.
Our goal is to provide an elegant and intuitive way to present your information
or product to your users or customers.

New Software offers a wide range of services:

• Building new web sites ranging from simple informational pages to sophisticated sites with dynamic content and advanced user interfaces.
• Designing and implementing company intranets and databases to improve internal company communications and access to information.
• Redesign and updating of existing web sites to enhance ease of use, performance, and impact.
• Consulting to help you choose features and make cost benefit trade offs while building your site.
• Long term maintenance agreements to keep your site current.