This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: RepositoryBasedCode
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
<p><b>NOTE: if you are still reading this feed, I should remind you that THIS FEED IS NO LONGER ACTIVELY MAINTAINED. Please go to <a href = "http://martinfowler.com/bliki/RssFeeds.html">http://martinfowler.com/bliki/RssFeeds.html</a> for information on my current active feeds.</b></p>
<table>
<tr>
<td style = 'font-size: larger; font-style: bold'><a href = 'http://martinfowler.com/bliki/RepositoryBasedCode.html'>RepositoryBasedCode</a></td>
<TD valign = 'bottom' width = '15%'><a href = 'http://martinfowler.com/bliki/design.html'>design</a></TD>
<TD valign = 'bottom' width = '20%'><b>15 January 2008</b></TD>
<TD valign = 'bottom' width = '10%'><a href = 'http://technorati.com/search/http://martinfowler.com/bliki/RepositoryBasedCode.html'>Reactions</a></TD>
</tr>
<tr>
<td colspan = '4'>
<p></p>
<p>An alternative to <a href = 'http://martinfowler.com/bliki/SourceBasedCode.html'>SourceBasedCode</a> is the idea that the
core definition of a system should be held in a model and edited
through projections.</p><p>To talk about this style of environment I find it handy to
think in terms of multiple representations of the system:</p><ul><li>editable representation: what you edit in order to change the
system.</li><li>storage representation: the persistent record of the system
definition.</li><li>executable representation: what is executed to make the system run
- the executable.</li><li>abstract representation: used to manipulate and reason about
system definition.</li><li>visualization representation: a non-editable view of the system
definition.</li></ul><p>A source based system combines the editable and storage
representations in the source file. It executes the source by
transforming the source into an executable representation either in
one observable step (interpretation) or multiple steps via a
compiler. In order to do this it usually transforms the source into
an abstract representation as an intermediate step, but this
abstract representation is transitory and only around during
compilation. The source is seen as the core definition of the
system.</p><img src = 'http://martinfowler.com/articles/compile.gif'></img><p>With a repository based system the abstract representation is the
is core definition of the system. A tool manipulates the abstract
representation and projects multiple editable representations for
the programmer to change the definition of the system. The tool
persists the abstract representation in a storage representation,
but this is entirely separated from any of the editable
representations that it projects. The relationship to the executable
representation is pretty much the same - the executable is produced
through a series of transformations from the abstract
representation. </p><img src = 'http://martinfowler.com/articles/workbench.gif'></img><p>An important difference between repository and
source based environments is the split between persistent storage
and editing. Repositories can choose any persistence mechanism that
they choose, while source systems need to have some universal
storage mechanism - which is why they are almost always text files.</p><p>The abstract representation may be edited through multiple
projections, each projection can show a limited amount of the total
information which isn't tied to the actual structure of the abstract
representation. Repository systems thus usually show a wider range
of editing environments - including graphical and tabular structures
- rather than just a textual form.</p><p>Sophisticated source based IDEs also show multiple projections -
for instance a side pane showing a list of methods for a class with
graphical annotations to indicate their
<a href = 'http://martinfowler.com/bliki/AccessModifier.html'>AccessModifiers</a>. However these projections are usually
very much secondary to a source editor, and often the projections
can't be edited directly - you have to change the source and see the
projection update.</p><p>Such <a href = 'http://martinfowler.com/bliki/PostIntelliJ.html'>PostIntelliJ</a> IDEs do this by creating an abstract
representation when they load the source files (which is why they
can take a while to start up). They also use the abstract
representation to do perform lots of other code-assistance features
such as contextual code completion and refactoring.</p><p>A significant pragmatic problem with repository based systems is
the fact that there is no generally accepted way format for the
storage representation. The fact that programmer-readable text is
the universal choice for source files means that a whole slew of
tools can be built to process them: editors, source-code control,
difference visualizers etc. Repositories have to do all this
themselves, which is often why these things are often lacking. In
particular many repository based environments suffer greatly because
they don't have a decent configuration control system, which makes
it much harder for multiple people to collaborate on the same system
definition. This is a big contrast to source based environments that
have a plethora of source code control systems to do this task.</p><p>Repository based systems are closely connected with Model-Driven
Development (MDD), although I don't think the two are entirely
synonyms. In an MDD context the abstract representation is usually
referred to as the model. Certainly almost all MDD tools are
repository based, but many all repository based tools, eg
Microsoft Access, would not consider themselves to be MDD.</p><p>(I first explored this way of looking at environments in my essay
on <a href = 'http://martinfowler.com/articles/languageWorkbench.html'>Language
Workbenches</a>. I've described it here because I think the notion
of repository based environments is broader than just in Language
Workbenches.)</p><hr></hr></td>
</tr>
</table>
Previous Topic
