3

I've recently been playing around with PostSharp, and it brought to mind a problem I faced a few years back: A client's developer had produced a web application, but they had not given a lot of thought to how they managed state information - storing it (don't ask me why) statically on the Application instance in IIS. Needless to say the system didn't scale and was deeply flawed and unstable. But it was a big and very complex system and thus the cost of redeveloping it was prohibitive. My brief at the time was to try to refactor the code-base to impose proper decoupling between the components.

At the time I tried to using some kind of abstraction mechanism to allow me to intercept all calls to the static resource and redirect them to a component that would properly manage the state data. The problem was there was about 1000 complex references to be redirected (and I didn't have a lot of time to do it in) Manual coding (even with R#) proved to be just too time consuming - we scrapped the code base and rewrote it properly. it took over a year to rewrite.

What I wonder now is - had I had access to an assembly rewriter and/or Aspect oriented programming system (such as a PostSharp) could I have easily automated the refactoring process of finding the direct references and converted them to interface references that could be redirected automatically and supplied by factories.

Has anyone out there used PostSharp or similar systems to rehabilitate pathological legacy systems? How successful were the projects? Did you find after the fact that the effort was worth it? Would you do it again?

UPDATE: See this blog post for more discussion.

Andrew Matthews
  • 3,006
  • 2
  • 29
  • 42
  • I could do that with AspectJ, but PostSharp seems to limited to be able to do too much with it, IMO. – James Black Oct 09 '09 at 03:51
  • @aabs: Renewtek, there in Melbourne, is using DMS on mainframe software. – Ira Baxter Oct 09 '09 at 04:53
  • Hi Ira, as I explained, we found it was easier in that case to discard the old code, so I don't need any services right now. I'm more interested in the idea that an IL rewriter or a program decompiler and recompiler (which I believe PostSharp can do BTW) is capable of tackling more fundamental issues of architecture. Not just idiomatic conversions. it sounds like DMS is more than capable. Is AOP capable, and if not why not? – Andrew Matthews Oct 09 '09 at 05:19
  • On re-reading my question I realize it might be unclear: I want to be able to take a crazily designed, tightly coupled P.O.S. and apply AOP, SOA, or program transformation, techniques to at least allow me to address issues of coupling, location dependence, volatility, insufficient abstraction etc. I want to retroactively redesign an app without rewriting the code. They can then clean up the code at their leisure while still being able to scale etc. A lot to ask? – Andrew Matthews Oct 09 '09 at 05:24
  • @aabs: wasn't suggesting services (you already said you'd thrown it away :), just that these tools are in wider use than readers here might expect, and point you to a local application. Can you arbitrarily refactor? Probably not, because in theory you can't reason about Turing machines. However, our experience shows that systems that aren't braindead can be salvaged, and the business rules in the existing code don't need to be rediscovered as happens in a manual rewrite. Its almost impossible to replace a running system because of its hidden knowledge. Moral: Don't lose it. – Ira Baxter Oct 09 '09 at 05:51

1 Answers1

4

What you want isn't AOP, but a program transformation system, which generalizes AOP. These allow one to define a set of automated modifications to the code base, and carry them out reliably. You don't hand modify 1000 complex references; instead you figure how to define a transformation that will handle all the cases and let the tool apply it reliably for you.

I can't speak for your web application, but I have two specific examples where I have applied this successfully.

1) Boeing needed to radically restructure up to 6,000 components, each coded as set of cooperating C++ classes (often totaling 3-10K SLOC) from a legacy distributed architecure to one in which each communicating element became a function in a CORBA facet. Using my company's DMS Software Reengineering Toolkit, a program transformation system capable of accurately transforming C++, we implemented a tool to carry out those changes. The tool modified one line in three on average but could convert a component in about 5 minutes. The resulting conversion was 98% complete and required some modest touch ups, but was much more effective than the estimated 1 man-month to hand modify each component. This is best thought as tool-implemented massive rearchitecting of the software structure. You can read about this in a technical paper:

Akers, R., Baxter, I., Mehlich, M. , Ellis, B. , Luecke, K., Case Study: Re-engineering C++ Component Models Via Automatic Program Transformation, Information & Software Technology 49(3):275-291 2007. Available from publisher.

2) The USAF has legacy systems that fly. One of these is the B-2 bomber, which is full of the world's best 1975 microprocessors. The code running in these is/was JOVIAL, the Air Force's favored langauge before Ada became the favored language (before everybody wimped out and now only awful languages are contemplated by the military for software engineering). The code runs the airplane. OTOH, they needed to get out of JOVIAL, because the support for the microprocessors (e.g., physical availability of CPUs, of development tools, and even of people willing to learn JOVIAL) was fast diminishing. We built them a JOVIAL-to-C translator using the same DMS, and accomplished 100% conversion, without ever being able to see the original code (black program...) See B-2 bomber conversion for some additional details. The B-2s are being upgraded with the converted software as we speak.

Now, both cases took some manual time to configure the transformations. But the configuration effort was tiny compared to the estimated cost to do the job by hand.

So, yes, such tools work very well if you understand how to use them, and yes we absolutely intend to use them again.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
  • Fully agree with this. AOP won't help here, it solves different (and much more simple & clear) problems. – Alex Yakunin Oct 09 '09 at 04:14
  • Err... I mean AOP won't help here as well. But automatic software refactoring is dream too. Cross-language conversion is pretty normal, but I know the quality of such conversion is far from good yet. Especially if you're converting to language offering higher level abstractions (conversion to low-level languages is pretty simple - it is normally called "compilation" ;) ). Conversion of Java to C# is a good example: converted program won't use delegates, events, lambdas, LINQ and so on. But yes, it will work. – Alex Yakunin Oct 09 '09 at 04:21
  • Naive, one-to-one translators produce mediocre translations at the same level of abstraction. However, one can analyze the context of code, and find better mappings to the target; this isn't a one to one translation. Neither is what a really good compiler does; it generates code for *this* action in the context of the surrounding code, and it can often outcode people that are really familar with the target archtecture. Similarly, one can code transformations that take into account special cases and context. This is easier if one decides to do this for certain special cases in advance. – Ira Baxter Oct 09 '09 at 04:25
  • As an interesting example, in one circumstance I handled the software apparantly needed to send a message, recieve a response, and then send another. By checking the recieved response didn't control whether the second message got sent, I was able to code transforms that produce a single packet containing both messages in it, with a corresponding transform on the recieving side to unpack things. The resulting code is clearly much better performance. Special operations in target languages require some preplanning to use, but are within scope of what these tools can do. – Ira Baxter Oct 09 '09 at 04:29
  • @Alex: "... automatic refactoring is a dream, too..." Read the paper. – Ira Baxter Oct 09 '09 at 04:55
  • Wow. thanks for such detailed and thoughtful responses. PostSharp, aside from Laos the AOP part, is also an IL rewriter, and it was in that capacity that I wondered whether it, or something like it, could fix *bad archiecture*. I'm less concerned about escaping from legacy languages and platforms... – Andrew Matthews Oct 09 '09 at 05:03
  • Check out the links. DMS isn't an "IL" rewriter; rather it is a "source to source" transformation system that uses compiler data structures internally to model the source code extremely precisely. (IL rewriting can't give you back source code, let alone the original comments :) – Ira Baxter Oct 09 '09 at 05:13
  • I knew about DMS, but this is plain awesome! – akuhn Dec 15 '09 at 00:10