Summary

Chapter 5 - Reverse Engineering
byAndrew Filevet al.?
Wrox Press ©2002

	Team FLY

This chapter began by noting why a reverse engineering feature is useful at all - for whatever reason, it's likely that we'll have some existing code that we'd like to incorporate into our Visio UML model.

Next we looked at how the source code of any Visual Studio .NET solution could be reverse engineered into a Visio UML model, and discussed some of the key features and limitations of this reverse engineering facility. In particular, the location of the relevant help documentation, the reverse engineering granularity, the fact that static structure diagrams are not drawn automatically, and the limited extent to which round-trip engineering is possible.

We looked at an example VS.NET solution, and used it to investigate the following:

• The reverse-engineered model structure

• Some of the important mappings between code constructs and UML notation

In the second half of the chapter we discussed a technique for reverse engineering any compiled .NET assembly - no source code required. This technique helps to bring Visual Studio .NET and the Visio EA reverse engineering feature closer to the standard set by other UML modeling tools, like Rational Rose, which provides for reverse engineering of compiled Java byte-code (.class files) as well as source code (.java files).

The technique is even more valuable when you consider that it allows any third-party library to be reverse engineered, so that you can show your usage of those third-party classes in your UML design model. Taking this to its logical conclusion, it opens up the possibility of starting any UML project with a base model containing representations of the .NET Framework classes themselves.

	Team FLY