It is difficult, if not impossible, to reverse engineer the requirements of a legacy application and to re-architect it in one go. 

This is one of a series of blogs connecting the principles described in the Use Case 2.0 ebook to agile legacy modernization.  The principles are:

1. Keep it simple by telling stories
2. Understand the big picture
3. Focus on value
4. Build the system in slices
5. Deliver the system in increments
6. Adapt to meet the team’s needs

For purposes of this discussion, let’s assume the reader is familiar with waterfall development criticisms and understands the concept of slices defined in the new Use Case 2.0 ebook.

It is difficult to reverse engineer the requirements of a legacy application and to re-architect it in one go and would violate most of the agile modernization principles. The big picture is best understood through bottom-up validation of user goals and the associated stories. Nor does a waterfall approach allow focus on value. There is no differentiation of those parts of the system most useful to the stakeholder.

You can identify slices by identifying the most useful things that an application does, the end-to-end, most straightforward way the user achieves a goal. Fit these stories into the ‘big picture’ use case model to provide context.

Use case slices are also the basis of estimation, test and connection to legacy code. Thus, in addition to it being a valuable tool for for reverse engineering the functional model, it is the basis for packaging related test and implementation elements. Extending the Use Case 2.0 concept of slice to legacy modernization, we see that the use case slice allows a connection beween the legacy and re-architected solutions.

Complete reverse engineering of the legacy design may not be necessary, but it may provide important information. Bringing the application into an object oriented paradigm may also guide the new architecture (see Legacy Applications and OO Technology).

Connecting to legacy code is important, because it shows the extent of code coverage. Legacy code, while not sufficient by itself to understand a legacy application, can remain a source of truth during modernization. Even though this blog emphasizes vendor-neutral methodology, it is clear that only automated solutions can provide the necessary traceability and model mapping.

The use case slice is common to the legacy and modernized applications.

(This figure is adapted from the Use Case 2.0 ebook ^[1])

As you can see, test assets are tightly integrated. Testing has always been a key part of use case technology. Extending this to slices makes the connection explicit. For new development, test should be integral. For legacy applications, it may be useful to gather existing test assets and test the legacy and modernized slices in parallel.

Slices provide a way to link requirements to the parts of the system that implement them–in both legacy and modernized contexts. Tests show whether requirements have been successfully implemented and allow you to compare results with the legacy application.

Use Case Realization has alway been part of use case technology.  It describes how a particular use case is realized within the design model, in terms of collaborating objects. To that concept we can add slices in order to connect a functional model to the legacy and modernized implementations.

1. ^[1] http://www.ivarjacobson.com/Use_Case2.0_ebook/, page 4 ↩

Actual system use is the basis for determining value. 

This is one of a series of blogs connecting the principles described in the Use Case 2.0 ebook to agile legacy modernization.  The principles are:

1. Keep it simple by telling stories
2. Understand the big picture
3. Focus on value
4. Build the system in slices
5. Deliver the system in increments
6. Adapt to meet the team’s needs

Agile use case modeling for legacy modernization tries to retain essential business functionality, and not start from scratch. Use case technology is a means of focusing on the existing value of the legacy application and adding value, Principle #3 of Use Case 2.0.

User goals and the associated stories are the mechanism for estimating, prioritizing and tracking functionality. They are the basis for use cases slices and the associated work items. In other words, prioritized functionality is connected to project work items. Focusing on the stories that provide value is a natural way to prioritize work items.

User goals are based on current use of the system, which may deviate from the intended use, back when the legacy application was first written. The primary goals provide the main flows. “… start with the simplest possible way to achieve the goal.” ^[1] For system re-architecture it is important to identify up front the most valuable system functions. To avoid waterfall development, make these valuable stories the basis for re-architecture. The alternative ways of achieving the user goal will provide the alternative flows and may receive lower priority.

Legacy modernization is clearly not about re-creating obsolete functionality or dragging dead code into the re-architected application. Understanding the functional model is an important basis for knowing what is current and what has no value for the user. The goal is not to create a user manual for the legacy application, but to understand current, key capabilities. Modernization is thus an opportunity to manage scope and focus on the most direct route for reaching user goals.

The use case model can be used to identify  important new user goals and the associated stories. The use case model and underlying details provide scope control and iteration planning. Depending the scope of new functionality, it may be necessary to identify legacy baseline functionality and identify new functionality separately in the model. Use case modeling provides techniques differentiating current vs. new functionality. There are several different possible approaches, e.g. use of the extends association use case model versioning, etc.

As we will see with use case slices (Principle #4). it is necessary to connect stories to the legacy code. Mapping use cases flows to specific parts of the code may require an automated solution. It can be significant if portions of code are not exercised via the identified functions.

1. ^[1] http://www.ivarjacobson.com/Use_Case2.0_ebook/, page 7 ↩

Understanding the complexities of a legacy application requires a top-down, bottom-up approach. 

This is one of a series of blogs connecting the principles described in the Use Case 2.0 ebook to agile legacy modernization.  The principles are:

1. Keep it simple by telling stories
2. Understand the big picture
3. Focus on value
4. Build the system in slices
5. Deliver the system in increments
6. Adapt to meet the team’s needs

Although written with greenfield development in mind, Use Case 2.0 is easily adapted to the world of legacy modernization. We will walk through each of the principles described for application to legacy modernization.

This discussion is based on the following assumptions:

• you want to modernize your legacy application
• you want to retain essential business functionality, not start from scratch
• you’re interested in vendor-independent practices
• you’ve set the goal of reverse engineering a functional model

Capturing the functional behaviour of an application involves and bottom-up, top-down approach. This corresponds to the first two principles of Use Case 2.0:

1. Keep it simple by telling stories
2. Understand the big picture

Presented with the task of understanding a legacy application, it is easy to get lost in detail or miss the larger context. One of the ways to keep it simple, is to start with the most important legacy functionality, i.e. user stories. Begin by understanding user system roles. Examine user goals when using an application. Achieving a goal is the basis of a user story. Initially it is important to capture the main flow and avoid alternate possible flows, exceptions to achieving the goal. Interview stakeholders about how they use the system.  Start with stories key to the business. Add exceptions and alternate endings only in subsequent iterations to achieve a complete picture. Isolating individual stories is the beginning of an agile modernization practice.

Assemble Use Cases from Stories

Use case models define the scope and provide an overall view. But the initial, high-level view need not be complete, detailed or final. Early in the project it is enough to gain a high-level view that can be refined. After initial functional reviews, the use case model should include user interaction, batch functionality and system interfaces, in other words a complete functional overview.

Establish a Top-down View of the Legacy Application

One effective technique for an draft use case model is to assemble key system users for a white board session. Do this without access to the legacy application in order to avoid getting lost in detail. The techniques are similar to those used in greenfield development.  The actors you identify will have goals when using the system.

Identifying stories in parallel with the use case helps us reverse engineer the functional model. Unlike some modernization approaches that overwhelm with detail, the approach here is separation of concerns and multiple views. As we look at the other ‘First Principles’ we will see how to use this model in the context of agile software modernization.

Image courtesy of Anthony Seebaran. Visit http://www.anthonyseebaran.com and http://www.istockphoto.com/awseebaran

It is possible to apply agile development practices to legacy modernization. The often cited disadvantages of waterfall development apply equally to modernization projects. If you have to completely understand and document the legacy application before writing a line of new code, you will incur tremendous risk.

Let’s see how the principles described in the recent ebook can facilitate agile modernization.

Subsequent blogs will detail each principle and what it means in the context of legacy modernization. The goal is to build on extensive use case experience for application to legacy modernization and leverage state-of-the-art knowledge about use cases.

Use-Case 2.0 exists as a proven and well-defined practice. Although the term Use-Case 2.0 suggests a new version of use cases, it does not refer to an update of the Unified Modeling Language, but rather to cumulative changes in the way software developers and business analysts apply use cases. A use case is still a use case but the ways that we present, address and manage them have all evolved to be more effective. The changes are not theoretical but are pragmatic changes based on 20 years of experience from all over the world and all areas of software development. ^[1]

1. ^[1] http://www.ivarjacobson.com/Use_Case2.0_ebook/, page 4 ↩