Sdílet prostřednictvím

Software Factories

  • Článek

This week I’ve been working on a paper that we’ll publish in Software Development magazine that explains, at least very briefly, how Visual Studio Team System (VSTS) will support the first step forward for our concept of software factories.  As soon as it’s ready for publication, I’ll post the link here. We’ve started to collect some material on the software factory concept on a website https://softwarefactories.com but due to my severely limited html skills, this website is still under development. I hope soon to have a real website developer improve it considerably J.

 

Software factories are more than just a strategy for modeling tools and DSLs. IMO, they are a necessary step if the software development industry is to respond to rising technological complexity and expectations of users.  Here’s a brief excerpt from the paper I just mentioned:

 

A software factory is a product line that configures extensible development tools like Visual Studio Team System (VSTS) with packaged content and guidance, carefully designed for building specific kinds of applications. A software factory contains three key ideas: a software factory schema, a software factory template and an extensible development environment:

· Think of the software factory schema as a recipe. It lists ingredients, like projects, source code directories, SQL files and configuration files, and explains how they should be combined to create the product. It specifies which DSLs should be used and describes how models based on these DSLs can be transformed into code and other artifacts, or into other models. It describes the product line architecture, and key relationships between components and frameworks of which it is comprised.

· The software factory template is like a bag of groceries containing the ingredients listed in the recipe. It provides the patterns, guidance, templates, frameworks, samples, custom tools such as DSL visual editing tools, scripts, XSDs, style sheets, and other ingredients used to build the product.

· An extensible development environment such as VSTS is like the kitchen where the meal is cooked. When configured with the software factory template, VSTS becomes a software factory for the product family.

To press this analogy further, the products are like meals served by a restaurant. Software factory stakeholders are like customers who order meals from the menu. A product specification is like a specific meal order. The product developers are like cooks who prepare the meals described by the orders, and who may modify meal definitions, or prepare meals outside the menu. The product line developers are like chefs who decide what will appear on the menu, and what ingredients, processes, and kitchen equipment will be used to prepare them.

 

The paper will give some more concrete examples, but hopefully you’ll see that this is the start of a way to think about software development using pre-defined content such as frameworks and software components, patterns – both design and architectural, development processes and tools.  When VSTS is first released, this “recipe” bundling will be non-automated, or possibly only partially fleshed out, but as time goes by, more of the process of defining “recipes” can be automated, and the software factory vision filled out. The Whitehorse tools, of course, being an implementation of a few key developer-oriented DSLs, are part of this vision, and will be part of VSTS as I’ve described elsewhere.

Comments

  • Anonymous
    June 26, 2004
    Maybe I'm missing the point on software factories, but at some level I think they should be driven by a domain of the WSDL - or perhaps a superset of WSDL.

    I am working in an area where we expect to see > 50 classes of services. Assume we define all of these services in a large "Here is the universe of WSL for this domain" Assume further that we decide thta, say, EBXML (and the WSDL that implies) defines the processes I want to wire up to instances of the 50 services types described above.

    If VSTS understood that, and that alone, would it qualify as a factory yet? If not, what would be missing?

    I know format and UI are another important area for a factory, but for simplicitly, let's make it a middleware factory for now.

  • Anonymous
    June 29, 2004
    Toby, I think you are getting the point. Making VSTS understand a family of applications defined around a common set of WSDL/EBXML would constitute a software factory. Of course you'd probably also want to do things like highlight which Web service patersns you'd like developers to use, where the points of variability existed, any Web service configurations such as security policies that should be applied, and specify any DSLs that should be used (like a business process definition tool). You may also want to add any guidance in terms of development process that you'd like the developers to follow and define that to VSTS as well. And so on. But you've definately got the idea.

  • Anonymous
    March 18, 2008
    PingBack from http://desktopcomputerreviewsblog.info/keith-shorts-weblog-software-factories/

  • Anonymous
    May 26, 2009
    PingBack from http://castironbakeware.info/story.php?title=keith-short-s-blog-software-factories

  • Anonymous
    June 09, 2009
    PingBack from http://quickdietsite.info/story.php?id=300