The software factory is not a new idea. Japanese companies in
particular have employed factory-like approaches to software construction.
During the 1980s, Japan’s
larger computer manufacturers, including Hitachi,
NEC, Toshiba, Fujitsu, and Mitsubishi all were engaged in extensive “software factory”
approaches to software development [CUS03]. These companies defined software
factories as applying factory-style methods and philosophies to improve
software development. These methods included:
n
Centralized project management
n
Standardized tools and methods
n
Reuse of system components
These approaches have proven successful in improving software
construction in situations where the problem at hand is exceedingly well
defined and constrained, which is not a place most software project find
themselves.
The Microsoft
Way
Microsoft creates the tools more developers use to build
software than anyone else. In 2005, Microsoft defined a software factory as “a
development environment configured to support the rapid development of a
specific type of application.” [Gre04]. This is a markedly different view from
the philosophical ideas of the Japanese software factories. To begin with, it
is a pragmatic definition, not a philosophical one. As Microsoft explains in
their .NET overview:
Figure 1: Component roadmap
|
|
To understand the .NET runtime, you must understand this:
The .NET runtime is designed to give first-class support for modern
component-based programming - directly in the runtime. In other words, it's all
about components. If you understand this, understanding why the .NET runtime is
designed as it is becomes much easier. [MS03]
This strong statement reflects a consistent evolutionary path
of Microsoft tools and technologies. Without a doubt, Microsoft is, and has
been, very firmly committed to component based development at the programming
level, which is significantly different than at either the process,
design, or philosophical levels.
The “Software Factory” however is a controversial metaphor.
Proponents say it represents an enduring vision for software development,
following in the path of the great industrialized efforts, from clothes to
foods to machines and now to software. Critics argue that the metaphor
over-simplifies the development process, doing more harm than good. The
critic’s typical contention is twofold:
1. Development versus Production. The purpose of an assembly line is
production. However, in software,
strictly speaking there is no production. The primary issue in software is
development, and development is not akin to production. If you want to compare apples to apples, they
say, software design and construction should be compared to factory
design and construction.
2. Software is a malleable digital product, not a physical
good, and therefore subject to different dynamics. For example, software does not wear out. In addition, unlike physical products, the
customer expects their software product to change after receipt, in terms of
patches, upgrades, etc.
Clemens Szyperski, a component proponent and software
architect with Microsoft Research has suggested that we might consider a
software factory as a special kind of factory, where the product being
assembled is a software factory [Szy03].
Consider the automobile assembly line. On these lines autos are
typically assembled piece by piece by a series of robotic machines. In our
factory metaphor, the product the developer is building is these robotic
machines.
For a small to medium complexity application this metaphor can
be overly complex. For example, we typically only need to develop one
application, not one thousand. Where is the benefit to building a robot that
builds the application for us? Can it
build other applications (application domains)? Can it adapt to evolving
requirement sets in real-time?
The software factory, like an assembly line, presupposes a
waterfall methodology whereby most or all requirements and details have been
worked out up-front. Japan’s
experience with software factories reinforces this. Michael Cusumano, in his book The Business
of Software notes: “…software factories seemed designed and best suited for
companies building product lines, similar systems, or well defined products
with domain constraints” [Cus03].
But what about the rest of us?
Can’t we just ignore factories and use the parts instead? Indeed, the greatest risk with software
factories may be that their inherent complexity causes us to lose sight of the
original value Eli Whitney recognized: Assemble complex products from
pre-built parts.
Parts
Software components are like standard reusable parts – and
as such, they could spur an industrial revolution in software, shifting the
emphasis from hand-crafting to assembly.”
Clemens Szyperski & David G. Messerscmitt
If the ultimate evolution of software production is to follow
other manufacturing models, it is the interchangeable part (component) that is
most lacking today and the greatest obstacle towards realizing this vision.
But what exactly is a software component? Bertrand Meyer
offers possibly the best real-world criteria for what a component needs to
support in order to be useable as an interchangeable software part [Mey00]:
1.
May be used by other software elements (clients)
2.
May be used by clients without the intervention
of the components developers
3.
Includes a specification of all dependencies
4.
Includes a precise specification of the
functionalities it offers
5.
Is usable on the sole basis of that
specification
6.
Is composable with other components
7.
Can be integrated into a system quickly and
smoothly
To support this criteria, a component’s structure should be:
Encapsulated It
protects its implementation from us, and vice versa
Descriptive Both us and the framework can
discover it’s services
Replaceable We can easily swap in new versions
In addition, a component should contain:
Interface The
contract that specifies what the component will do
Implementation The
component’s underlying code
|
Encapsulated
|
Yes. Client does not
typically modify the inside of an alternator
|
|
Descriptive
|
Yes. A schematic is
typically published in alternator’s manual.
|
|
Replaceable
|
Yes. Author has personally
done it.
|
|
Interface
|
Yes. Typically 3
electrical terminals.
|
|
Implementation
|
Yes. Sub-components
inside the metal casing make an electric charge.
|
|
Package
|
Yes. There is a metal
case that bolts onto the car’s engine.
|
Package The
physical component file (in .NET this is the DLL or “assembly”)
Apply these criteria to the alternator in a typical car’s
engine:
Figure 2 :
Alternator as component
Figure 3: Typical alternator schematic
There is one significant aspect missing: an alternator is
not is extensible. One does not typically upgrade or patch an alternator.
When it is replaced, it is replaced with an exact duplicate of itself, often
made by a different supplier. This is perhaps the most significant distinction
between physical components and software components: Customers do not expect
the functionality of a hardware component to change over time.
An alternator is also a collection of parts itself. This
principle of reusable parts used to make more complex reusable parts is the
building block of complexity and in itself reveals the true strength of
decomposition by component.
Having discussed the requirements for a software element to
act as an interchangeable part in a software application, we can now define a
software component.
Software Component : A Software Component is a
reusable, self-describing piece of software that can be independently deployed
and integrated with other software parts without modification.
During the web hysteria of the late 20th century,
component based development practices (CBD) were hyped as the next “silver
bullet” to solve the software complexity issue. Most of the web companies are
gone, but what about the hype?
The software industry is wary but not immune to the lure of
silver bullets, which underscores the strong understanding and desire among
many to improve predictable software development. Developers, however, are at
worst quick to dismiss anything containing the word “methodology” and at best
simply pragmatic. Since developers construct software, lets look at CBD from a
developer’s perspective.
From a pragmatic viewpoint, components are a good thing. We
know this because we know software is hard to write, and if can reuse another
piece of code, especially if it is code we don’t want to write, we will.
Software factories, however, and we’re not so sure. The question then is, How can we benefit from
components without incurring the overhead of the “software factory”? More importantly,
how do components influence how we currently build software? Where exactly do
components fit into our existing methodologies? For this paper we will borrow
the term Component Based Development to simply mean that collection of tools
and processes (practice) that help us answers these questions.
Component Based Development (CBD) : Component Based
Development is the practice of developing software by assembling software
components.
To develop software, basic questions about the software
project must be answered. At a minimum we must know:
n
What are we building?
n
How are we going to build it?
To answer these two basic questions, the software industry has
produced numerous methodologies. Most methodologies involve some form of
the following activities:
Figure 4: The
software lifecycle
Over the past 50 years this software lifecycle has changed
precious little. We have, however, established ways of doing it. In particular,
we have established:
n
Development Paradigms
n
Design Paradigms
n
Programming Paradigms
The following diagram relates software lifecycle activities to
these paradigms:
Figure 5: Paradigms applied to the software lifecycle.
The development paradigm applies to all stages of the
lifecycle. It is a meta-paradigm in that it seeks to model the software
lifecycle itself. The Design and
Programming paradigms are more often used by developers, and included specific
tools and structures for performing specific programming related activities.
Component based development impacts all of these paradigms.
Some software groups use methodologies (Extreme, Agile, RUP,
Waterfall) and some do not. How does CBD work with these existing
methodologies? Are we better off without one? There are certain development
paradigms that are simply not well suited for component based development.
Evolutionary prototyping, for example, presumes a software project’s features
cannot be known up front, but are evolved iteratively through interactions with
the customer. Components, by definition have their features declared up front.
Unless we can evolve the component’s feature set, evolutionary prototyping will
not work.
The following table is a brief summary of suitability issues
between CBD and existing software development methodologies.
|
|
|
|
|
|
None
|
High
|
Provides stability and structure in an otherwise
ambiguous process
|
Difficult to justify expense
High risk of components not interoperating
|
|
Waterfall
|
High
|
Up front spec allows selection of components
|
|
|
Evolutionary Prototyping
|
Mixed
|
Components can provide instant prototype
|
Cannot evolve components
|
|
Spiral / RUP
|
Mixed
|
Working software significantly reduces risk
|
Can depend on length of iterations and “specability” of
features
|
|
Extreme / Agile
|
Low
|
|
Cannot refactor components
|
Figure
6: Suitability of component based development (CBD) for common
methodologies
The following is a simple example of a component based
lifecycle as applied to the waterfall method.
Figure 8: CBD alongside the waterfall
The preceding diagram suggests that most of the additional
work required when doing component based development is at the front end, where
specification and design lead to component selection. While this maps neatly to
waterfall processes, there is no reason why these considerations can’t be
applied to any particular methodology.
To be clear, when we talk about the design paradigm we are
talking about architecture, which is to say, how are we going to build this
system, specifically? At this level, what requirements are unique to component
based architectures? Components typically
1.
Require a model or framework (e.g. CORBA, COM,
.NET) that specifies assemblage
2.
Implement specific “design patterns”
3.
Relate strongly to architectural decomposition
4.
Make design assumptions that may not be readily
apparent
The Microsoft .NET platform has significantly enabled the
practice of CBD because of the first and most significant item : a component
framework. The .NET framework is large, robust, backed by Microsoft, and
exceedingly easy to use for novice and experienced developers alike. These
factors support Microsoft’s claims of revolutionizing software development
through what they term software factories.
What the .NET platform does not provide for is the remaining
three. Specifically, while there is a component platform and an increasingly
growing number of components available to developers, there is no factory
whereby these components can be rapidly assembled into meaningful applications.
While there are a growing number of components in the toolbox, what is not
present is a guide to architectural
decomposition along component boundaries. This is where application doma
