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.

Published Interface is a term I used (first in Refactoring) to refer to a class interface that's used outside the code base that it's defined in. As such it means more than public in Java and indeed even more than a non-internal public in C#. In my column for IEEE Software I argued that the distinction between published and public is actually more important than that between public and private.

How do you represent derived information in the UML?

A laptop on a keyring, well in many ways this can only an exaggeration, but the idea has been intriguing me recently. The catalyst was coming across Knoppix.

An acronym for: Plain Old Java Object.

A project timeline is a valuable thing to produce during a project retrospective. A timeline should show the various events that occurred during the project, and how they affected the project.

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?

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.

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

CalculateChargeCommand.new(aContract).run()

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.

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.

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.

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++.

One of the most useful design principles that I've found and followed is that of keeping a good separation between the presentation aspects of a program (the user interface) and the rest of the functionality. Over the years where I've seen this done, I've seen plenty of benefits:

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.

How do you show local variables (parameters, temps etc) on UML class diagrams?

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.

What is the difference between dependency and association?

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?”

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.

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.

I don't think applications are going away for the same reasons why application boundaries are so hard to draw. Essentially applications are social constructions:

Where did the word refactoring come from?

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.

There are many common examples of ValueObject, my favorite is Money - and one closely linked to Money is currency.

What is the difference between a UseCase and XP's UserStory?

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 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.

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.

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.

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.

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.

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.

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.

History is more or less bunk

-- Henry Ford

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.

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.

My colleague Joe Walnes pointed me to a fascinatingly simple tool developed by our colleague Chris Stevenson. TextDox (part of AgileDox) is a tool to automatically generate documentation from JUnit test cases. Sounds ridiculous, but then that's what Wardish ideas are like.

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.

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.

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.

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:

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.

To build a platform by harvesting, you start by not trying to build a platform, but by building an application. While you build the application you don't try to develop generic code, but you do work hard to build a well-factored and well designed application.

A Foundation Platform is a that is built prior to any application that are built on top of it. The idea is that you analyze the needs of the various applications that need the platform, then you build the platform. Once the platform is complete you then build applications on top of it. The point is that the platform really needs to have a stable API before you start work on the applications, otherwise changes to the platform will be hard to manage due to their knock-on effects with the applications.

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.'

In this UmlMode developers use the UML to help communicate some aspects of a system. As with blueprints you can use sketches a forward engineering or reverse engineering direction. Forward-engineering draws a UML diagram before you write code, while reverse-engineering builds UML from existing code in order to help understand it.

If you can detail the UML enough, and provide semantics for everything you need in software, you can make the UML be your programming language. Tools can take the UML diagrams you draw and compile them into executable code.

The promise of this is that UML is a higher level language and thus more productive than current programming languages.

For a long time engineering influenced software processes have looked for a way to express software designs in such a way that the designs can be handed off to a separate group to write the code, much as blueprints are used in building bridges. This would allow rare and expensive software designers to concentrate on the blueprints while many cheaper coders concentrate on construction.

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.)

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.

If I want to teach people object-orientation, which language should I use?

Can you use refactoring to build a platform?

Few things in the UML cause more consternation than aggregation and composition, in particular how they vary from regular association.

CHAOS report says only 34% of projects succeed.

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'?

Is it good OO design to have data in my classes with the protected AccessModifier?

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.

Lets say you have an album class which has an ArrayList of tracks. How do you show this in a UML class diagram?

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.

Why chaos theory suggests that component assembly may not be as easy as it's cracked up to be.

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.

My IEEE column on the valuable contributions that patterns can make to understanding software 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 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.

Guidelines on when to make a new user defined type (or class) for values.