by David O'Leary and Don Benage
Although the software development industry has many unique characteristics that distinguish it from other endeavors, an on-going attempt is being made to adapt ideas from other engineering disciplines to advance the speed and reliability with which you can build complex software solutions. In some other engineering fields, such as mechanical or chemical engineering, a more rigorous scientific approach has been adopted. Although the software development industry is still in relative infancy, it has the opportunity to build and use tools to improve itself like no other industry has before, due to the nature of software development.
Just as a carpenter would never build a sizable project without first drawing up a plan, most software development efforts are complex enough to require a general plan of system parts and how those parts should interact. Creating a model that represents a complex system allows you to better understand the individual components of the system, the relationships between components, and the ways in which they interact. The model allows you to focus on these important design decisions before getting too involved in the myriad details that must eventually be addressed. It can also help the project participants understand the modeled system more quickly and easily. Microsoft is promoting Visual Studio as an important step in the evolution of software development tools. The core idea behind this message isn't new and unique to Microsoft: Instead of crafting an application as a single entity, most applications are built by assembling existing components (ActiveX controls, COM/DCOM objects, OLE-enabled applications, and so forth) together to create a custom application. Just as a car is made up of various parts (frame, engine, fuel system, exhaust system, drive train, and suspension) and some of these parts can be interchanged between different models of cars, it should be possible to design interchangeable software components.
This elusive concept dates back to good programming practices introduced with the development of procedural structured programming. These practices were then extended by other innovations, such as object-oriented programming, the use of dynamic link libraries (DLLs) and Visual Basic custom controls (VBXs), and the various object systems such as COM/DCOM, SOM, and OpenDoc. What Visual Studio adds to this concept is a suite of tools, each with its own strengths, designed to work together. Potentially, these tools can maximize the capability to create applications quickly by assembling pieces developed by using the various tools.
Visual Modeler is a fairly easy tool to use. (In fact, getting the tool may prove more difficult than using the tool, but that will be explained.) The difficult part isn't the tool, but the underlying language on which it's based--the Unified Modeling Language (UML)--and the concepts on which the UML was built. For that reason, this chapter focuses more on what Visual Modeler does and why, rather than how to do particular tasks. n
Microsoft designed Visual Modeler as an entry-level modeling tool. In this, its first release, Visual Modeler offers support for only a subset of the UML. It's an appropriate tool for those of you new to modeling. If you're an experienced designer, you can choose (or already might be using) a more fully featured modeling tool. Visual Modeler allows you to create the equivalent of blueprints for software systems. It uses a standard set of symbols and icons that you can use to represent an application or group of applications at various levels of detail.
Visual Modeler was created for Microsoft by Rational Software Corporation, with some additions made by Microsoft for better integration with Visual Basic. Rational offers Rational Rose, a full-featured modeling tool that provides support for several languages, including Visual Basic, C++, and Java. Overall, Visual Modeler provides a subset of the functionality in the Rational Rose/Visual Basic product. Rational Rose supports the full UML, whereas Visual Modeler doesn't. (This is discussed in more detail later in the section "The UML.") If you start with Visual Modeler and later decide to buy Rational Rose, you can open any models created with the Visual Modeler tool directly in Rational Rose/VB because they use the same file format.
NOTE: Rational Rose was designed for use with many different languages, development environments, and operating systems. For integration with a particular language, you buy an Analyzer program that handles code generation and reverse/round-trip engineering for that language. Current languages supported by Rational Rose include C++, Forte, Java, PowerBuilder, Smalltalk, SQLWindows, and Visual Basic.
For various reasons, including license restrictions between Microsoft and Rational, you must have Visual Basic installed on your computer to be able to run Visual Modeler. Also, Visual Modeler supports only code generation for and reverse engineering from Visual Basic, although this shouldn't restrict you to using Visual Modeler only on Visual Basic applications. Any sizable software development process can benefit greatly from using a visual-modeling tool. Whether it's designing classes and controls in C++ or Java, or defining the interface of a DLL, Visual Modeler is a very useful visualization tool whose benefits go well beyond its code generation and reverse-engineering capabilities. If you want the added benefit of being able to generate code for a language other than Visual Basic, you'll have to buy the full version of Rational Rose or another tool that supports the full UML and code generation in the language of your choice.
Visual Modeler is a key piece of this software development system. It allows you to design the system at several different levels so that, from a high level, you can properly see the various components needed for the application (see Figure 27.1). Then you can select existing components or choose the proper tool for developing new components.
FIG. 27.1
The Visual Modeler display uses a multiple-window design to let you view your current
model graphically, as well as a logical view with nested folders and a separate window
for comments.
NOTE: In the jargon of object-oriented software development, an object refers to an instance of a class. In the broader context of Visual Studio and the UML, however, you can use the term object to refer to a whole range of entities that contain a defined interface, actions, and attributes such as ActiveX controls, a module, or DLL. The UML defines an object as "an entity with a well-defined boundary and identity that encapsulates state and behavior. State is represented by attributes and relationships; behavior is represented by operations and methods."
You can't get Visual Modeler from the Visual Studio CD-ROMs (at least, not at the time of this writing); instead, you download it from http://www.microsoft.com/vstudio/owner. On this web page, follow the steps given to register Visual Basic (it must already be installed), click the Visual Modeler hypertext, and then follow the instructions for downloading. When it's registered, you can get a private access area from which you can download the Visual Modeler install program.
At the heart of Visual Modeler--and modeling tools in general--is an attempt to improve overall system design. Proper use of a modeling tool should increase the use of good programming principles such as encapsulation, abstraction, and reuse. These principles have been developed, primarily within the discipline of object-oriented software development, to help create and maintain large systems with fewer errors and better long-term cost-effectiveness.
Encapsulation is the idea that objects (classes, modules, and controls) should allow users to see only a limited and specific interface, the functions to be called, and the input and output parameters of those functions. The exact details of how they're implemented are hidden from the object's users. Having encapsulation is very important in software development. Without it, developers are tempted to build components that depend on the specific internal design of another (unencapsulated) component. If the component is later modified, one seemingly simple change can result in a cascading series of additional required changes.
For example, a car engine is an encapsulated part of an automotive system. One engine can be used in several different makes and models of cars, and a car can use several different types of engines (for example, four cylinder or six cylinder). That way, if one engine breaks, it can be replaced with another of the same type or even a different, but compatible, engine. The designers of other automotive components don't concern themselves with the specifics of the engine. They know only how it's mounted to the frame, attached to the exhaust system, and other similar interfacing details. They don't care how many cylinders it has, nor do they design other components that depend on a specific number of cylinders.
Abstraction is a process of focusing on certain aspects of a problem. Rather than require everyone to know and understand the implementation details of an entire system--or even a specific object within that system--with modeling you can show only the pertinent information to reduce the complexity involved in understanding a system. This makes the system easier to design and understand.
Many people may use the same object, but they need to know only the interface (the name of the functions and each function's expected input and output parameters). For example, someone who puts an engine in a car doesn't have to know about the internal workings but does have to know about the engine's interface, such as how to hook the engine to the transmission. As long as the interface requirements are known, the two objects can be designed and built separately and put together during an integration phase.
Reuse is a key concept of Visual Studio because it attempts to make software development quicker and more reliable by allowing developers to assemble already built components into a custom application rather than write from scratch. Reuse comes into play at many levels in application development from simply reusing one function to reusing components such as data combo boxes. You may even decide to reuse entire applications, such as Excel or Word, through Automation (formerly known as OLE Automation). Visual Modeler allows you to place existing elements into your model by reverse engineering them from code or their OLE interface. (See the later section "Reverse Engineering Wizard" for more details.)
Reuse is a natural byproduct of good encapsulation and abstraction. If you fail to use these principles during the design or redesign phase, you won't create reusable objects. Also, reuse tends to work from the micro level to the macro level. In other words, if you focus on the smaller objects, functions, modules, and abstracting generic functions out into separate general utility classes, what is and isn't reusable at the larger module level will become much clearer.
TIP: To maximize code reuse at the micro level, look for places where the same code is used several times in different places. If you find yourself cutting and pasting a piece of code, look for ways to move that code to a single function or even a class. If it's something that could be used in several applications, you might consider creating a DLL or an ActiveX control that exports this function and possibly other related functions.
Encapsulation, abstraction, and reuse are all very closely related, and together they lead to easier modification and maintenance as well as quicker and more reliable system development. Using thoroughly tested, prebuilt objects won't save you an immense amount of time during development; to use a prebuilt object, you must first find an object appropriate for your needs and then learn how it's properly used. Where you'll save time is during the testing and maintenance stages, and for the next project you'll already know the object's capabilities.
Encapsulation, abstraction, and reuse also make larger teams possible because of the reduced dependencies between objects. If objects aren't properly encapsulated, a team's members will constantly step on each other's toes as they try to integrate their individual system parts.
Preliminary design work results in better code. It also saves time in the long run by greatly increasing the encapsulation of the various objects of the system, resulting in easier maintenance, reduced complexity, and an increase in the amount of reusable code produced. On many projects, especially where budgets are tight, there's pressure to begin coding immediately. Although many organizations have learned the folly of this decision, it's shocking how often this still happens. There's no substitute for good design, and taking the time to do so will save money and time in the long run.
Modeling is one of the most effective tools for creating a good design. Modeling a system allows you to step away from implementation details, so you can clearly see how a system should be broken into components and how those components need to interact. When working directly with code, you easily can get stuck in the details and not see the big picture of the overall software system. If you forgo preliminary design work and then require continual redesign throughout the project, the system begins to develop a "bubble-gum-and-bailing-wire" character, which makes changes to the system very difficult.
The Unified Modeling Language defines a graphical notation to be used in designing and representing a software system. This graphical notation helps developers visualize the problem and its solution without getting overly involved in the implementation details. Just as an outline gives a higher level view of a document, or an architectural plan gives an overview of a building, the UML can be used to give a higher level view of a software system. This higher level view proves useful throughout the software development life cycle--through analysis, design, implementation, and maintenance. Figure 27.2 summarizes the evolution of the UML.
FIG. 27.2
The evolution of the UML, taken from the UML Summary document (with permission).
Developed by a consortium of individuals and companies, the UML is an attempt to bring together the most useful parts of the best modeling languages and combine them into a single language that can be used throughout the industry.
NOTE: The UML isn't a methodology--it's only a modeling language. A modeling language defines a way to graphically express a system model, whereas a methodology defines a method to use in designing and developing software. The UML should generally be used within the context of a methodology such as Booch, OMT, or one of the forthcoming UML-based methodologies.
The UML is ultimately the product of a long history of ideas in the computer science and software engineering area. However, three men did much of the development and unification work: James Rumbaugh, Grady Booch, and Ivar Jacobson. These three joined forces when they all began working at Rational Software Corporation and are now commonly referred to as the Three Amigos. Each worked independently or with another team to develop a software development methodology and a complementary modeling language to describe the various elements of the methodology and their interactions. Each methodology--or at least a part of each methodology--is still being widely used throughout the industry today.
ON THE WEB:Rational Software Corporation provides a complete range of software development tools, including tools for modeling, testing, and project management. Visit Rational's web site at http://www.rational.com/ for more information.
NOTE: Several tools support the full UML (including use cases, object interaction diagrams, and so on), including
- Rational Rose by Rational Software (www.rational.com)
- Select OMT by Select Software Corporation (www.select.com)
- Paradigm Plus by Platinum Software (www.platinum.com)
Just as a building blueprint can contain several different diagrams, each describing various aspects of the building, different types of diagrams can be used together to describe the many aspects of a software system. Before modeling a system, it's important to have an idea of who you're producing the model for and how it will be used. Different audiences often require vastly different views of the system. The diagram produced for developers will be quite different from the model produced for a client. Management will be interested in a much higher view of the system than a class implementer.
Visual Modeler provides for a variety of views into the system. Not only does Visual Modeler have a number of different diagram types, but it also has varieties of each diagram type. Each diagram allows you to describe different aspects of the system for various audiences and purposes. Some systems require only a few of the diagrams to be defined, whereas others use all of them.
The UML defines the following graphical diagrams:
| Use-case diagram* | Sequence diagram |
| Class diagram | Collaboration diagram |
| Behavior diagrams | Implementation diagrams |
| State diagram* | Component diagram |
| Activity diagram | Deployment diagram |
*Not supported by Visual Modeler
Visual Modeler adds two more diagram types to this list, both of which are variations on the class diagram: the three-tier diagram and the package overview. The three-tier diagram is used for the highest level view of the system and its architecture. The package overview is used for low-level details. The following sections provide an overview of a few key diagram types supported by Visual Modeler, when to use them, and what the various elements describe.
The three-tier diagram is a form of class diagram and is used as the highest level (see Figure 27.3). It separates the class diagram into three tiers, allowing you to view and better understand the separation between tiers in a multitiered architecture.
FIG. 27.3
The three-tier diagram makes it easier to understand the components that make up
an application's various tiers.
NOTE: Multitier architecture is a paradigm used to complement other modeling techniques. A three-tier architecture is often used, although more tiers are possible. This architecture frequently has a direct correspondence to the physical location of components: desktop computers for client components, middle-tier servers with business-rule objects, and database servers.
Visual Modeler describes the three tiers as follows:
Class diagrams came from the object models of OMT and Booch (see Figure 27.4). They show the classes of the system and their relationships, and optionally, each class's attributes and operations. Representing the system through class diagrams comes with a great deal of flexibility. You can show every class in the system with all its attributes and operations, or you can break the system into many different packages, each with their own class diagrams.
FIG. 27.4
Class diagrams provide details about a particular class and its relationship to other
classes.
How you decide to represent the system depends on the intended audience and the intention behind the model. If you're preparing a class diagram to be used by the developers who will write the code, your model will contain a high level of detail. You would prepare a model with less detail, using class diagrams for only the major elements of the system, to present an overview to management.
When constructing a model, as with many other activities, being able to group elements based on a variety of criteria is useful. This grouping then allows you to more conveniently work with and manage the elements of the group. Visual Modeler has such a grouping mechanism known as a package, which is a collection of classes with a strong relationship to one another. Therefore, a package represents a logical chunk, or piece of, the entire system. Packages may be nested within other packages. To avoid confusion with component packages (described in the following section), it's best to refer to this type of package as a logical package if it's not already clear from the context in which it's being used.
A package overview is created and updated automatically when you create a package. As classes are added to the package, they're also added to the corresponding package overview. Although packages don't correspond directly to any construct in Visual Basic, they're frequently used to represent OLE Automation servers.
Whereas packages represent logical chunks of the system, components are the physical elements of the system. Whereas packages don't correspond directly to Visual Basic constructs, components correspond directly to code modules. Components include executable applications (EXE files) and application extensions (DLLs). A component package is a group of related components. The role of component packages is similar to that of the logical package introduced in the preceding section, but it's a grouping of physical components rather than logical classes (or class diagrams).
A component diagram, therefore, represents a view of the various physical pieces of a system. It depicts the individual components, component packages, and the relationships between these elements. Component diagrams are sometimes referred to as module diagrams, although the newer term component diagram is now preferred.
Each component and component package has a corresponding specification that contains its properties. While the properties are viewed and edited in textual form in Visual Modeler, some of this information can be displayed inside the icons representing the components and component packages in component diagrams. When you edit a specification, Visual Modeler automatically updates all diagrams containing the icon for that component or component package. You can also directly edit the diagram, and the corresponding specification will be revised.
Through a combination of the logical and component views, it's easy to define the responsibilities and interfaces of classes and components of the system. Each developer can then begin his or her design, knowing the expected inputs and outputs of any given module.
Each model contains a single deployment diagram. This diagram takes another step toward the actual physical implementation of the system by showing the nodes, or actual hardware units that will run the system, and the connections between the various nodes. Each node and connection has a corresponding specification, which can be edited directly in the icons of the deployment diagram or in more detail by directly accessing the specification itself. As with component diagrams, edits made in either fashion are reflected throughout the model in any view.
The deployment diagram, by modeling the actual physical environment where the system will run, can provide important information regarding potential time delays introduced by slow links connecting the various nodes, and other real-world artifacts of the intended environment. Although this information may be implicitly reflected in the physical partitioning represented by component diagrams, it's not directly depicted in any other diagram and is an important addition to help provide an overall understanding of how the finished system will function.
A handful of elements are used to create all the diagrams in Visual Modeler. They may take on a slightly different form or meaning depending on how they're used, but the same elements are still used. This way, it's easier to learn how to use Visual Modeler and to understand the created diagrams, much as the consistent use of visual elements such as toolbars and menus has made other computer software easier to learn and use.
The following sections describe the major elements common to the various diagrams: classes, objects, attributes, operations, and relationships.
A class--one of the fundamental elements of object-oriented analysis and design--is an important concept to understand when using Visual Modeler. It's one of those fundamental concepts that's easier to grasp and use than it is to describe. Although a complete description of the term class is beyond the scope of this book, in its most basic form a class is nothing more than the description of a group of like objects, with similar properties and behaviors. It's easy to think of many real-world object types that may be represented by a class--cars, humans, invoices, a car loan, and the manufacturer of a car are all examples. In addition to tangible things, processes also can be represented by a class.
A class is represented on an object model as a hard (square-cornered) rectangle, called a class compartment. A class compartment can display up to three sections, depending on the view options you select. There's always a section for class name, and it may also have sections for attributes (properties) or operations (behaviors).
In object-oriented terms, an object is an instance of a class. For example, Joe Smith is an object and a member of the class Person. He is also a member of many other classes, such as male, human, mammal, and so on. All the classes of which he is a member are related by what's called inheritance, described later in the section "Generalization (Inheritance)." An object is represented with a soft (round-cornered) rectangle.
NOTE: As mentioned earlier in this chapter, an object can also be used to generically reference an instance (or occurrence) of several different element types, including ActiveX controls or components. As a rule, the word object refers to a particular element rather than that element's type or class.
The term attribute is used to designate a characteristic of an object or a class. For any given instance of a particular class, a given attribute takes on a specific value. For example, color is an attribute of the class car. A specific car might be the color blue. With characteristics like color, it's generally easy to determine that they should be modeled as attributes. The color of a car should almost always be modeled as an attribute.
In some cases, however, it's not so straightforward. The engine can be viewed as an attribute or as another object with a defined relationship to the car object. If the engine's details are important in describing the system to your audience, the engine should be modeled as its own object and should have a component relationship to car. If you care only what type of engine it is (for example, four cylinder), as you would for the car's invoice, the engine can be modeled as an attribute. It all depends on the level of detail you're trying to communicate to the users of the model.
An item should never be an attribute and a component object. Attributes appear in Visual Modeler as descriptive text on the various icons in the model.
An operation is defined within the UML as "a service that can be requested from an object to effect behavior. An operation has a signature, which may restrict the actual parameters that are possible." Unfortunately, because of the large scope of objects that this definition applies to, this definition isn't very workable. In general, think of an operation as a function. Whether it's in VB, C++, Java, JavaScript, or an exposed function in the API of a DLL, an operation is something you call on to perform an action or get information.
Within class diagrams, operations appear in the bottom (third) section of a class.
Relationships between classes are a key part of class diagrams. Knowing how and when objects will interact has a major effect on how classes are designed and implemented. Just as objects in the real world must have a variety of relationship types, objects in a software system must interact in various ways to perform their responsibilities. For example, if you were to model a car by using the UML, the car would be composed of parts or systems such as the engine, fuel system, electrical system, and so on, and it would have a relationship with several other objects, such as a driver (driven by), gasoline (consumes), and a mechanic (is fixed by). Cars also have a special relationship with other vehicles, in that all vehicles have common attributes. This type of relationship is referred to as inheritance and is discussed in further detail later in the section "Generalization (Inheritance)."
NOTE: Since the release of UML 1.0, quite a bit of controversy has occurred as to the actual meaning and implementation semantics of the different types of relationships. The definitions are intentionally somewhat vague to allow for application to various languages and tools and to keep the language from being overly restrictive.
The UML defines five fundamental kinds of relationships: association, generalization, dependency, transition, and link. The two primary types of relationships, association and generalization, are described in the following sections.
Association An association is the most general form of a relationship. Aggregation and composition are both forms of association. If a class has any knowledge of another class, whether it's passed in as a parameter or is a member of the class, there should be an association between those classes. An aggregation is a special form of association that shows a relationship between a whole (the aggregate) and its parts. Aggregation implies a strong dependency of the aggregate on the part, but not as strong of a dependency of the part on the aggregate. For example, a car needs an engine to be useful, but an engine can have a life outside of a particular car; they're independent entities, yet there's a definite dependency. Aggregation is represented in the UML (and Visual Modeler) by a hollow diamond.
Composition involves a stronger dependency between the whole and the part than aggregation. For example, consider a car and its frame; a car must have a frame to be considered a car, but a car without an engine is still thought of as a car. Composition is represented in the UML by a solid filled diamond.
Constraints allow you to further restrict or specify relationships. The most common type of constraint, multiplicity, allows you to define an exact number of associations between two objects. You can also specify multiplicity in terms of ranges. You also can add textual constraints to any relationship. A textual constraint can be any text that specifies a relationship, but most often is a verb that describes the interaction between the objects.
Generalization (Inheritance) Generalization, a specialized type of association, is also known as inheritance or specialization. Unfortunately, the definitions of generalization and inheritance are more confusing than helpful to novices:
Inheritance is useful as an abstraction concept and for reducing the amount of code that needs to be written and maintained. Inheritance, a concept of object-oriented programming, isn't truly supported by object-based languages such as Visual Basic.
Object-Oriented Versus Object-Based
Inheritance is the main concept that separates object-oriented languages such as Smalltalk, C++, and Java from object-based languages such as Visual Basic. Inheritance makes a considerable difference in the way a language is used and how reuseable objects and classes are written. With Visual Basic, creating controls or modules to perform certain functions extends the language. Programmers can then use those controls in a customized way, depending on what customization options were built into the control. Or, if you have the code, you can copy that code into your own class or control and customize it to meet your needs. With inheritance, you can extend an existing class by inheriting that class's operations and attributes and then specializing its behavior by overriding existing functionality and adding additional functionality. However, an inheritance change to the underlying base class affects all inherited classes that didn't directly override that modified behavior.Just as in good database design, you want to minimize the number of places that data resides so that changes have to be made in only a few places. Code works the same way.
Inheritance is a very important concept in object-oriented development and, when used correctly, can greatly reduce development and maintenance time and frustration.
For a model to be effective, it must closely parallel the actual system that it models. In the case of computer software, the characteristics of the model(s) should align closely with the actual computer code that makes up the project. Also, as the project changes to meet new requirements or respond to real-world requirements, it's important that the model and code stay in sync when they're modified to reflect the new information. Visual Modeler provides a number of tools and techniques to help make sure that this relationship exists and is maintained throughout the life of your project.
Two tools in Visual Modeler aid the process of keeping the model of a given system in sync with the code that's written to implement that system: the Code Generation Wizard and the Reverse Engineering Wizard.
After you create a model, Visual Modeler can automatically generate classes, function stubs, and comments in your project. You control which elements of the model code gets generated for. You can choose to let Visual Modeler automatically generate code for your entire model or select specific elements of the model. You can also control what's generated and how it looks by configuring options in the Code Generation Wizard.
To use the Code Generation Wizard, follow these steps:
FIG. 27.5
Use the Select Classes dialog box to determine the classes for which code will be
generated.
FIG. 27.6
With the Preview Classes dialog box, you can preview the code that will be generated
for a specific class and change options as required, before actually generating the
code.
FIG. 27.7
The General Options dialog box allows you to change settings that affect the code
generated for all classes in your model.
Even if you never performed any design work on your application, Visual Modeler can read through your code and create an object model that contains all classes, modules, controls, and relationships. This can be very useful for improving your system architecture, adding objects, doing additional design work, finding reusable code, or acquainting new people with the existing system.
Through the Reverse Engineering Wizard, you can customize what types of objects and relationships are created and drawn. To bring up the Reverse Engineering Wizard and set configuration options, follow these steps:
FIG. 27.8
The Selection of Components dialog box allows you to save your project and model
before the reverse-engineering process as a precaution.
FIG. 27.9
Use the Assignment of Components dialog box to group your components into packages.
After importing all the various elements from the project, Visual Modeler draws the diagram and attempts to space and group the various elements in a readable format. You'll find that you usually need to do quite a bit of reorganizing, however, to make the diagram more readable and useful.
FIG. 27.10
The Finish dialog box summarizes the impending reverse-engineering process to give
you the opportunity to review the outcome before it occurs.
Round-trip engineering allows you to keep your model in sync with your code, and vice versa. Round-trip engineering is really just a combination of code generation and reverse engineering. With round-trip engineering, however, you get the advantage of having code and comments properly formatted by the Code Generation Wizard so that they, with any changes, can be properly imported back into the model and changes in the model can be reinserted into the code.
This is particularly necessary for keeping comments synchronized. In this way, you can completely use everything you've done from start to finish without throwing away any of your work, and yet it still allows an iterative development life cycle.
The use of tools such as Visual Modeler is growing. After years of debate and refinement, the practice of object-oriented analysis and design is now generally accepted as being a useful way to create good software, perhaps even the best that's now available. Few modern projects created for environments with distributed databases, I-net technologies, and multitier archi-tectures would be undertaken without these techniques. Tools such as Visual Modeler that directly support specific languages in a tightly integrated fashion are important to the success of large projects. For more information on some of the topics addressed in this chapter, see the following chapters:
ON THE WEB:For a look at multimedia creation tools for I-net applications, see "Web Content Creation Tools and Utilities" on the G. A. Sullivan web site at http://www.gasullivan.com/vs97book/.
© Copyright, Macmillan Computer Publishing. All rights reserved.