My friends are all geeky, so many of them were looking forward to
the day in November 2003 when the extended DVD of The Two Towers
came out (and among my friends the extended DVD was the only one
worth having.) But for me that day marked another release that was
in many ways just as important, Sergio Leone's great western finally
made it onto DVD.

An important thought for anyone building services for a service
oriented architecture. When you build your service, also build a
service stub that your clients can use to test against. Such a stub
should provide canned responses to a fixed set of requests, simulate
error conditions, and be runnable on a client's machine. You'll need
to ensure that the stub mimics the true systems behavior
properly. By providing a stub for your clients, you make it much
easier for your clients to use your service; which of course means
that your service is more likely to be used.

I'm currently sitting in a session at XP day where Owen Rogers and Rob
Styles are talking about the differences between XP's unit and
acceptance tests. This triggered a thought in my mind - what should a
language for writing acceptance tests be?

The most common style of interface to a module is to use
procedures, or object methods. So if you want a module to calculate a
bunch of charges for a contract, you might have a BillingService class
with a method for doing the calculation, calling it like this

aBillingService.calculateCharges(aContract)

A command oriented interface would have a command class for each
operation, and be called with something like this

The UML means different things to different people, which is why
I find the notion of people using a different UmlMode
useful. Most people I talk to are interested in
UmlAsSketch and this group isn't very impressed with UML
2.

So far refactoring tools
have appeared for a number of languages. After Smalltalk's lead, we've
seen several tools for Java and a couple for C#. One language
conspicuous by its absence is C++, despite appeals.
All this despite the fact that the first refactoring thesis was done
by Bill Opdyke, who's
background is in C++.

You have a piece of functionality that you need to add to your
system. You see two ways to do it, one is quick to do but is messy -
you are sure that it will make further changes harder in the future.
The other results in a cleaner design, but will take longer to put in
place.

In general, you use an association to represent something like a
field in a class. The link is always there, in that you can always
ask an order for its customer. It need not actually be a field, if
you are modeling from a more interface perspective, it can just
indicate the presence of a method that will return the order's
customer.

In the very earliest days of Object-Orientation, the OO advocates
like me put a lot of attention into arguing in favor of reuse. Early
on we talked about reusing of classes. Then we discovered that reusing
individual classes, while it worked in some cases, didn't work so well
elsewhere. So we got into reusable frameworks, which got us part-built
applications of functionality.

This question struck my mind a few times when writing the
refactoring book. I knew the term was used within a fairly small
community, so in order to discover the etymology of refactoring I
talked to the people in that group (Ward Cunningham, Kent Beck, Bill
Opdyke, John Brant, Don Roberts, Ralph Johnson...) to find what had
led them to come up with the term.

All agile methods stress the importance of direct interaction
between the developers of a system and customers who are its
eventual beneficiaries. The agile manifesto said "Business people
and developers must work together daily throughout the project",
which is there to stress the high frequency of interaction. Extreme
Programming stresses this through its practice of OnsiteCustomer.

When data modeling methods talk about relationships, they use the
term cardinality to indicate how many entities may be linked
together. So you might have a relationship between order and
customer and say that the cardinality of the relationship is
one-to-many. Or you might hear that the cardinality of customers for
an order is 0-to-many.

A common complaint about patterns books is that they have nothing
new to tell experienced developers. (I've had a few of these recently
in amazon reviews and on The Server Side, so perhaps I'm feeling
sensitive at the moment.) Not just is this true, but it's the whole
point of patterns.

Many people belive that you can't do a fixed price contract in an
agile project. Since the whole point of an agile process is that
you cannot predict the future, this isn't an unreasonable
supposition. However this doesn't mean you can't come up with a fixed
price agile contract, what it really means is that you can't come up with a
fixed scope contract.

I recently got an unhappy email from a reader of UML Distilled. It's
never a good start to my day when an irate reader regrets buying, let
alone reading, my words of occasional wisdom. But there was something
particularly interesting about this reader's beef. His concrete
complaint was about my 'unnecessary history'.

When we think about software architecture, we usually think
about its technical architecture. But there's also another important
architecture - the one we use to communicate with the customers of the
software: the marketing architecture. Neglecting this "marketecture",
and its relationship with the "tarchitecture", can get
development projects into a lot of trouble.

This last week I had the pleasure of wandering around Florida
speaking with Dan Sandlin and David LeBlanc at a series of Microsoft
architecture councils. For those who don't know David LeBlanc
wrote the very popular book Writing Secure
Code with Michael Howard. At each of the session I would do a
talk / q&a on P of
EAA (which got a JavaWorld award this week) and David would follow on security.

Last week the OMG adopted the superstructure document for UML
2. In practice this means that UML 2 is agreed on. There are
numerous changes to the UML in UML 2 - it represents the biggest
overhaul to the UML since the UML was originally agreed on. For
general users the most obvious changes are probably:

A recent piece by
Robert Cringely caused a small stir in the refactoring community
recently, as he criticized refactoring. Phlip summed the response on
the refactoring
mailing list with an unusually restrained '...he sounds like a
"skeptic" who writes reviews of books he has no intention of
reading.'

I've been watching the blog scene develop for a while, and it's
impossible to not want to join in. But there are things I'm not so
keen about blogs. For a start the name, as my colleague Mike Two puts
it, "blog sounds like something I should pay a physician to
remove". Beyond the name, however, there's the very ephemeral nature
of blog postings. Short bursts of writing that might be interesting
when they are read - but quickly age. I find writing too hard to want
to spend it on things that disappear.

It's a common question, and the short answer is that yes,
refactoring is very useful when building a framework. But the issues
involved depend on the state of life of the framework, and
particularly in the approach you use to building a framework.

The Standish Group's CHAOS report has been talking of billions of
wasted dollars on IT projects for many years. The 34% success rate is
actually a improvement over 2001's figure of 28%. But what do we
really mean by 'failure'?

Object-oriented languages divide a program into modules called
classes. Each class contains features, which consist of data (fields)
and methods. (Not all languages use these terms, but they'll do for
this.) Languages have various rules about what other classes can
access the features of a class, these are often based on access
modifiers that apply to a class.

A common question is whether large projects can be done with agile
techniques. After all many agile approaches are designed for smaller
projects and the heavyweight ideas that they resist are more needed on
bigger projects.

Software Development magazine adapted chapter 7
(Distribution Strategies) of my book Patterns of Enterprise
Application Architecture as an article in their magazine. I suspect
they liked it due to its tone and the inclusion of the First Law of
Distributed Object Design.

As XP and other Agile methods gain popularity, questions
are beginning to surface regarding how to scale XP beyond teams of
10-12 people. In mid February 2003 a workshop dedicated to the
subject was held in Banff Alberta Canada. In this article we report
on the keynote speeches from Ken Schwaber, and Martin Fowler, as well
as other leading practitioners.

Over the last few years we've developed a number of
techniques that allow a database design to evolve as an application
develops. This is a very important capability for agile methodologies.
The techniques rely on applying continuous integration and automated
refactoring to database development, together with a close
collaboration between DBAs and application developers. The techniques
work in both pre-production and released systems.

This is one of those anti-patterns that's been around for quite a
long time, yet seems to be having a particular spurt at the moment. I
was chatting with Eric Evans on this, and we've both noticed they seem
to be getting more popular. As great boosters of a proper Domain
Model, this is not a good thing.

Most of the clients I run into have not heard of iterative
development, or consider it to be a new and relatively untried
phenomenon. In contrast iterative development has been around for a
long time under various names. A recent article by Craig Larman and
Vic Basili in IEEE Software summarizes an effort to capture this
history and gives you a good idea on the long story of successful
projects that use iterative development approaches.

A common part of encapsulation, particularly with
object-oriented systems, is hiding data structures. Yet it's also
common to expose much of this data behind data access routines. In
this column I cover some guidelines for writing data access
routines. However don't forget that if you can leave the data hidden,
that's usually better.

Just recently I've picked up a couple of bad reviews on Amazon
for P of EAA because there is nothing in the book about enterprise
architecture. Of course there's a good reason for that - the book is
about enterprise application architecture, that is how to design
enterprise applications. Enterprise architecture is a different
topic, how to organize multiple applications in an enterprise into a
coherent whole.

Every XP aficionado knows about the 4 values and 12 practices,
but how many people know about the 15 principles? I'll confess I
didn't when Kent talked about them at JAOO last week. After the talk I
asked Kent about them: "were they in the White Book". "Yes", he
replied, "cunningly hidden in a chapter called 'Basic Principles'".

All of this site is written in simple XML documents and
transformed to HTML. I find this works really well, and means I
never have to worry about dealing with HTML formats. (Not that fancy
layout is my style, as you can tell.) I've even written a whole book
that way.

One of the big claims about Model Driven Architecture (MDA) is
that it allows you to develop a system in a Platform Independent Model
(PIM) that can then be transformed into Platform Specific Models (PSM)
for technologies such as .NET or Java. An alert reader should say to
this: "hang on a moment, isn't the whole point of Java to be platform
independent? So why would I want some platform independent technology
that generates another platform independent technology?"

One of the undecided problems of software development is deciding
what the boundaries of a piece of software is. (Is a browser part of
an operating system or not?) Many proponents of Service Oriented
Architecture believe that applications are going away - thus future
enterprise software development will be about assembling services
together.

We see so much emotional discussion about software process,
design practices and the like. Many of these arguments are impossible
to resolve because the software industry lacks the ability to measure
some of the basic elements of the effectiveness of software
development. In particular we have no way of reasonably measuring
productivity.

This is a common question, and not one that has a generally
agreed on answer. Many people in the XP community consider stories
to be a simplified form of use cases, but although I used to hold
this view I see things differently now.

When people use the term 'software architect' they are using a
metaphor from building construction to help people understand the
architect's role.Ironically in doing this they misunderstand the
actual role of a building architect.

Look at most libraries that talk between application programming
languages and relational databases, and you'll notice that they map
the string type in the database (char or varchar) to a string type
in the programming language. Simple, obvious, but perhaps it's wrong.

The Singing Detective is a TV series (6 one hour episodes)
produced by the BBC in the 1980's. Many people, including me, consider
it the finest piece of television they've ever seen. It's a complex
piece, possibly one of the most original pieces of art ever made for
television. As such it isn't everybody's cup of tea, but I've watched
it many times. It's most noticeably associated with the writer Dennis
Potter, who made many challenging television programs. It's recently
become available on DVD.

Scratch any large enterprise and you'll usually find some kind
of group focused on enterprise-wide conceptual modeling. Most
commonly this will be a data management group, occasionally they may
be involved in defining enterprise-wide services. They are
enterprise-wide because rather than focusing on the efforts of a
single application they concentrate on integrating multiple applications.

What is architecture, and who exactly is an architect? These
are questions that seem to get everyone very heated. So in this IEEE
Software column, I let Ralph Johnson explain about
architecture: with a definition that matches all others in a
way that nobody agrees with. I also talk about two sub-species of
architect: Architectus Reloadus and Architectus Oryzus.

This is the month for review of the IEEE's Software Engineering Book of
Knowledge. This is an attempt to define the body of knowledge of
our profession, in a way that can lay the groundwork for a licensed
profession.

When people are starting to work with objects, particularly in a
strongly typed language, a common question is whether they should
have specific collection classes for different domain types. So if
you have a company class which stores a collection of employees,
should you use a regular collection class from your libraries, or
should you create a specific EmployeeList class - a
typed collection.

A common problem with test-enhanced designs is how to create
Service Stubs in test mode while letting the real thing be there for
production (and for some tests). A couple of my colleagues have
shared their ideas.

UML use case diagrams define a bunch of relationships between use
cases. The two best known are include and extend. There seem to be
more questions on these two relationships than on any other part of
use cases, perhaps even anything in the UML.

While I was looking at UML 2, it occurred to me that people
differ about what should be in the UML because there are differing
fundamental views about what the UML should be. As I thought about
this, I came up with three primary classifications for thinking about
the UML: UmlAsSketch, UmlAsBlueprint, and
UmlAsProgrammingLanguage. (Interestingly Steve Mellor
independently came up with the same classifications.)

Usually you don't show the collection on the class diagram as a
class. All you do is show an association between the album class and
the track class. By marking the association with a * multiplicity you
imply that a collection is in play.

Over the last couple of decades we've seen a growing gap
between database-oriented software developers and in-memory application
software developers. This leads to many disputes about how to use
database features such as SQL and stored procedures. In this article
I look at the question of whether to place business logic in SQL
queries or in-memory code, considering primarily performance and
maintainability based on an example of a simple, but rich SQL
query.

For quite a while now, I've been doing most of my writing using
XML - even to the point of writing my last book in XML. As I've
mentioned this to people they've asked me a number of questions about
my experiences, and that's been enough to prompt this little article
on the whole thing.