Jim Lavin

Its all 'bout re-use

  Home  |   Contact  |   Syndication    |   Login
  18 Posts | 0 Stories | 7 Comments | 0 Trackbacks

News

Twitter












Tag Cloud


Archives

Post Categories

My Other Blogs

When I look at Software Factories I see a chance to reuse resources in a major way. If you think about it, many of the foundations that Software Factories are built on are rooted in reuse initiatives.

When viewing Software Factories from a reuse perspective, what artifacts should a factory contain besides executable code? Should we include resources from all of the phases that make up the software development life cycle or should we limit the resources to just those needed to produce executable code? I am of the opinion that a Software Factory should include resources from all of the phases of the development lifecycle. Why not reuse the analysis and design artifacts? Their use would help to make the process more repeatable and consistent. Also, by reusing artifacts from the entire lifecycle process, we are helping to accelerate the completion of the entire project from analysis to steady state support. Not only can we provide the code, but we could provide starting point documents for the requirements, design, installation, and run-time support as well.

A list of the type of artifacts I could see being included are:

  • Requirements
  • Traceability Matrices
  • Business Rules Definitions
  • Use Case Scenarios
  • Design Diagrams
  • Unit Tests
  • Integration Tests
  • Acceptance Tests
  • Hardware Deployment Configurations
  • Deployment Steps
  • Application Trouble-Shooting Guides
  • Help-Desk Procedures

Thinking of the contents of Software Factories in this way means we have to think about the big picture. We need to look at everything produced during the development life cycle and decide how it fits in the factory schema and how we provide those artifacts in such a way that they are of value to the end-user.

Do we have our factory generate the artifacts in a series of documents or do we provide the ability to generate the output in several formats to allow it to be consumed by the various life cycle tools that are in use today? How do we store this information to allow it to be reused in so many different ways? Do we use text documents, XML, databases or do we need a repository to store it all?

If we look at how the Guidance Automation Toolkit (GAT) treats artifacts today, a source file has no significance until it is acted upon at runtime. The GAT treats it as an object, it doesn't compile it, it doesn't treat it in any special way, its just a file on the file system. In all reality, the GAT takes no special notice of it until it executes a recipe that references it and then the recipes and actions are the ones who understand its significance. They may use it as a template to generate a source file, they may add it to a project or they may even read it and use the data contained within it to pass to other actions or recipes.

Using this same principle, we should be able to do the same with all of the other lifecycle artifacts. Where appropriate, we can store the raw data in XML files and use T4 Templates to transform the data into any format we need for our life cycle tools. Graphical data can be exported to various standardized formats that can then be read in by our tools as well. We should be thinking of the GAT as a transformation engine and our artifacts as raw data that the recipes and actions transform in to format we need.

As you start to include more and more artifacts from the development lifecycle into your Software Factory, its complexity and size will increase. To handle this, you need to think about how you will standardize their format and transformation. Taking the time up front to define how you will store the information and what formats you'll provide for consumption will help you develop a library of recipes and actions you can reuse through out your projects.

To me, the use of XML data files to hold the raw data and the use of T4 Templates to output the data are probably the best way to do this at this point in time. It is very easy to read in a XML data source and then format it for output using the tools provided in GAT. Over my next few posts, I'll provide some examples of how to take a simple XML data file and transform it using T4 Templates.

Technorati Tags: , ,
posted on Wednesday, June 27, 2007 1:55 PM