Sybase has recently included impact analysis features into the PowerDesigner (PD) modeling tool. If you aren't familiar with PD, it's a powerful tool for modeling business processes, data designs, XML messages, and application logic (ala UML). Within each model, you can view the dependent objects (basically, what would be affected if you deleted something).

By using the repository, you get generational dependencies added to the mix, giving you a very powerful impact analysis. But that isn't all. PD has introduced a new type of model that links other models to each other. This is the Requirements Model (RQM), and it not only links models together, but individual objects can be tied to requirements and/or cross-linked to each other. With this functionality, you can ensure that each requirement traces through to implementation through the design elements. That means, quite simply, that by tying PD models together, you have a higher confidence that the original requirements are accurately represented in the solution. The impact analysis functionality is crucial to this idea and is fully implemented throughout every facet of the tool.

For this article, I will be investigating the latest available beta copy of version 12, since I love to be on the bleeding edge. There are some minor improvements over v.11, and it will be generally available to the public in early 2006.

Introduction to the Requirements Model
To begin the project, a business analyst creates a requirements model (RM) to capture the initial business needs. Individual requirements can be pasted in from Word or other documents, or you can import a Word document in its entirety directly into a blank RM. Many requirements documents I have seen are simply that, documents with paragraphs of text. The RM is substantially better, since each requirement is an object, encapsulating many properties underneath. By pasting information from other sources, you can embed a considerable amount of information on a single requirement, yet not muddy the waters if someone just wants to see a list of requirements. Many different views are available, similar to other models that can have multiple diagrams. This gives control over the level of detail presented to the user. Furthermore, model reports can be created as documents or Web sites and include as much or as few details as needed to communicate accurate information. Not only can you publish a report, but you can create a marked-up Word document with bookmarks for each requirement in the model. This provides bi-directional editing, so a business person can edit the document, and you can pull those changes back into the model easily. That means fewer copies of PD running around, and better control over the model management and methodology for creation/maintenance.

Requirements can be nested and grouped easily, so, for instance, everything tied to normal application usage is put together. Also, they can be tied to each other internally (such as a requirement for accurate customer address information being linked to a government filing requirement that is based on the customer address). Right away we have impact analysis available to document the dependencies between requirements. If I want to substantially change or even delete a requirement, PD helps me avoid tragic mistakes. The old delete confirmation dialog box from previous versions has been enhanced to include an "Impact Analysis" button, as shown in Figure 1. Every time I try to delete an object (in any model), that dialog is right in my face, making it very hard to ignore the impact of what I might be doing. Oh, and don't for a minute forget that PD has a very powerful undo/redo feature, so even if I do delete something with catastrophic results, I can reset everything back the way it was, as long as I don't save and close the file.

By clicking on the "Impact" button, you can view the dependencies and know if the deletion will have an impact on other areas of the model. This is a universal dialog box, visible whenever any model object is deleted from any type of model. Very handy.

Furthermore, the Tools menu has an Impact Analysis item. Select a model object (or a group of them), then click on the menu item, and you can view the dependencies that cascade from that object. The tree will look something like Figure 2.

Note that the selected entity "Member" has relationships to a number of other entities, specifically "Vendor Rep" and "Address State." These in turn have relationships to other entities. Also note the distinction between "Delete" and "Change." Those items listed as Change will be changed if the selected entity is deleted. Those listed as Delete will be deleted if the selected entity is deleted (relationships and other dependent objects). For the RQM, when other model types have been included and linked to requirements, then the display shows those other objects. The list tab of this dialog box allows the list of impacted objects to be sorted, printed, or saved to a file. This means any anomalies can be reported, investigated, and then resolved, as appropriate. Without visibility of the interactions that the impact analysis feature provides, you might not find "red flags" until much later in the project.

The RQM has another view that is even more valuable, the traceability matrix view. This depicts the requirements down the left side, and the dependent objects from other models acrossthe top, as shown in Figure 3.

Figure 3 provides the ability to easily link many requirements to many design objects. Just select an empty cell and click the "Create" button at the bottom. If the cell already has been selected, the button changes to "Remove," so you can delete the link, all with a simple button at the bottom of the screen. Another neat thing on this matrix view is that you can rearrange the columns (but not the rows) to group the impacted design objects together. Note that Customer History is shown twice, because I tied both the entity and table to the same requirement. An enhancement for Sybase might be to include an optional icon to distinguish design objects from each other (Entities from Tables in this case).

There are other variants of the traceability matrix, showing requirements dependent on other requirements, or requirements depending on specific roles. The view can be customized to hide empty rows/columns, to reduce the bulk of the display, or to show only empty rows/columns, to quickly locate requirements that are not implemented in any specific design objects.

Impact Analysis and Generation
Normal data modeling involves at least two models (CDM -> PDM), and potentially a large number of models. How bad could it get? Initially, a high-level CDM is created with only major entities (or subject areas) displayed. From this model, a series of mid-level CDMs are created to flesh out each subject area. Some CDMs are project-level, created as part of a specific development effort. Others are enterprise models created to document complex data structures outside of any single project. Selected CDMs are then generated into logical data models (LDM) to introduce IT-specific naming conventions and artifacts. In PD, these are PDMs with a special database target of "<Logical>". From an LDM, at least one PDM is generated with a specific database target, like Sybase or Oracle, and further enhanced to create the precise database objects required for the given system.

With that mess of models, how do you know where a specific entity or table came from? In Figure 4, highlighting the Version Info tab of the table properties dialog box, you will see the "Generated from" section, with the origin object. In this case, the Customer History table was generated from the Customer History entity, pretty straightforward. The button off to the right links you directly to that entity, so you can walk backward from the PDM table, to the LDM, the CDM, and any other models in the generation chain.

Impact Analysis and the Repository
The PD repository is a database that provides version control and enhanced model management features in larger shops, and impact analysis certainly plays a part here too. As stated briefly earlier, having the repository involved allows the "Impact Analysis" dialog to display the generational links between models. Initially, the dialog displays only dependencies internal to the current model. When you consolidate the models with dependencies between them, the extraction process can be made sensitive to those other models, as shown in Figure 5.

As an aside, there are a number of ways that models can depend on each other.

• Generation: For instance, I start with a CDM and generate a PDM. Those models are linked together.
• Shortcut: Using shortcuts, you can reference an object from one model in another model. This is useful if you have a master model of common elements you want to share, but only have to maintain a single copy.
• Replicas: Using replicated objects, you physically make copies from model to model, but the copies are managed by PD, preventing casual changes from "breaking" the copies.
• User-defined dependencies: You can use the "Extended Dependencies" tab of the properties dialog box, shown in Figure 6, to create and manage any extra dependencies you may want to use to link objects to each other. In my example, I have linked the Customer History entity in my model to a Purchase History table in a data mart model belonging to a sales decision support application. There is no generation link or real reference of any physical kind, but I wanted to document something, so PD lets me.

Once the models are consolidated and extracted (with the checkbox checked), the Impact Analysis dialog will include the other dependencies listed above. This gives total visibility of any and all links, including generation, shortcut, replica and any user-defined links you create, including the RQM requirements.

However, this isn't everything for impact analysis and the repository. Within the repository, I can search across all models for similar objects, and run my own queries and reports to show me anything I want to know about my models.

Summary
Impact analysis information is found in many places within the tool, from the powerful requirements model with its traceability matrix view, to the common delete confirmation dialog box.

Unfortunately, the full functionality and value of impact analysis can only be truly realized in larger models and massive sets of models, which would not fit in a single magazine article. However, even this brief coverage should help you catch a glimpse of the value and impressive functionality found in the PowerDesigner tool. With this unique set of features, PowerDesigner promotes much better quality in analysis and design from IT organizations.