Design – Benefits of Modeling Software Systems vs. Coding

Web pages are part of the visual presentation of your final implementation, and are not part of any UML Sequence Diagram language construct. Webpages would serve no purpose that is not alredy addressed within the current UML Sequence Diagram language and definition.

Additionally, by including a web page into any design document, you are presupposing a visual implementation. If you are strictly designing sequence logic, you should have NO preconceived notions as to how the visual implementation might look. (It's not a "website design diagram", it's a sequence-of-logic diagram.)

I find that you can almost always make a case to violate any guiding principle, design approach, teaming agreement, programming language paradigm, and even engineering "best practice". But these are (and should be) "red flags" that alert you to the fact that you are going outside of the original concept/reason for using whatever technique/tool/etc. you've chosen, and it will only lead to less rigor. Rigor, for its own sake, is not good or even necessary. But rigor constraining behavior for a specific goal is usually "A Good Thing(tm)", because it saves you from yourself - or from "misuing" (of sorts) the framework that you've selected.

Suggestions/frameworks/best practices exist solely to advise and constrain your behavior in favor of a particular outcome, and are based upon the combined experience of many, many very talented people. I don't recommend that you violate the UML Sequence Diagram construct by including webpages in the diagram, as this violates the rigor of the UML Sequence Diagram constructs, and it defeats some of its purpose (to remove visual - and other - considerations from what should be rather pure business logic and/or the interactions of your design).

I recommend that you stick to using the UML Sequence Diagram a little more literally - it's not a "website design diagram", unless THAT is what you WANT to make it. And if so, you might call what you are making a "website sequence diagram", though it seems to be a stretch...

It's up to you to use your tools as they suit your needs. But I wouldn't make this change lightly. =)

XP doesn't explicitly call for the creation of a model, but it doesn't say that one should never be produced. If developing a model helps you to build and then document your system, it should absolutely be done. The difference is that Agile Modeling has a different focus than system modeling in a plan-driven environment. In fact, the Agile Modeling site even addresses specifically how you model in an Extreme environment.

Agile environments take a more Lean (in the same sense of Lean engineering or Lean manufacturing) approach. Some of the key tenants include reducing waste, deciding late, and delivering fast. In order to eliminate waste, only the required documentation is delivered at the appropriate granularity. If you produce a work product, that work product is expected to ultimately add value to the customer - waste is considered anything that doesn't help add value to the person paying for it.

In fact, the XProgramming blog article you linked to supports this:

You may well need some nicely formatted UML for your project...If and when you really need these things, then by all means you should do them. But inside your collocated Whole Team, you most probably will not need them, because the information you need will be communicated through the more effective medium of conversation.

The Martin Fowler article that you linked to also supports this:

Certainly XP de-emphasizes diagrams to a great extent. Although the official position is along the lines of "use them if they are useful", there is a strong subtext of "real XPers don't do diagrams".

A central idea of the agile methods is "individuals and interactions over processes and tools". You don't follow a process or use a tool for the sake of following the process or using a tool. If the task that you are working on does not add value or if it doesn't produce something that is useful to someone (either the customer or another engineer), then you don't do it.

Martin Fowler goes on to say:

The primary value is communication. Effective communication means selecting important things and neglecting the less important. This selectivity is the key to using the UML well. ... A common problem with the common use of diagrams is that people try to make them comprehensive.

Again, same idea. The purpose of any documentation is communication. If you are producing things that don't help you communicate the system, why are you doing it? Don't focus on every little detail, but focus on communicating a message that provides useful, value-adding information to someone else.

Even later in the article, Fowler goes on to note that one of the problems with CASE tools is that they can fall out-of-sync. As soon as the code and the documentation fall out of sync, the document adds no value. I'd even take this a step further and say that it adds negative value, as it provides false and misleading information to anyone who tries to use it to make a decision. If you have a process to maintain synchronization, that's good. However, if you don't and you do let your documents fall out of sync, this brings up another question: why do you have them? They clearly aren't being used, or else they would be maintained.

Rather than some other model-driven methodologies requiring the models, even if they don't necessarily add any value, XP calls for spending time and resources on things that actually help you deliver value to the customer/client. If you can justify that certain models actually do add value to your project, then by all means you should produce them. However, you shouldn't be producing models that duplicate other information or don't add value.