Web pages in UML sequence diagrams?

Question

In my current project, we have an ongoing discussion about whether or not it's a good idea to include an artifact representing a web page in an UML sequence diagram for a web application, making explicit which page starts a business interaction.

I think it's a bad idea to include a web page, for me a sequence diagram should be about business logic and the interactions between business objects, and not include presentation concerns such as web pages. If I were to include a web page it'd be in a navigation diagram. Also, in my experience I had not seen web pages included in sequence diagrams, up until now.

What's the recommendation/best practice on this? Should we include an artifact representing a web page in each of our sequence diagrams, or not?

EDIT :

It'd be ideal if the answers quoted design/modeling guidelines, books on UML, etc. arguing in favor or in opposition to including presentation artifacts in UML design diagrams. So far I haven't found an authoritative source that I can quote on the subject, instead of personal opinions.

Answer 1

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

Answer 2

It is the abstraction that you form for the web page that matters -

For example, when users fill up a form and send a requests - the web page is essentially a source of initiation or response to user for a sequence of dialog (with say a back-end). In that case, the role of web page is no different from the client application in similar scenarios.

Sometimes, a key request may go to end server/service after several iteration with users - for example user may enter wrong password or user is not logged in which is redirected - such things can be omitted from the regular work flow assuming that user is authenticated.

If there are intermediate actions you want to define between how user interacts with buttons or other elements inside the page and how the page needs to react to it - in such cases UML could be a bad idea;

You need to define the exact purpose and scope of interaction to be plotted in appropriate sequence diagram.

Answer 3

You probably won't find any discussions/advise either pro or con to adding webpages to UML Sequence Diagrams because one traditionally has never had anything to do with the other.

It sounds like your colleague(s) believe that your project's UML Sequence Diagram is lacking some level of information.

You might ask them to explain exactly what aspect of the project's design is "missing" from the diagram, such that they feel the need to represent it pictorally. If you have them place this information into a bullet-list format, you might find that each bullet can (and should) be turned into a "standard/traditional component" of the UML Sequence Diagram.

That is to say, whatever information they feel is missing, and which should be represented visually, likely belongs as additional inputs/transitions/states/interactions within your diagram.

I suggest that you fix the diagram by adding the information that is currently missing from your diagram using traditional UML Sequence Diagram constructs, not by adding this missing information in the form of a pictograph.

Answer 4

The page doesn't actually start the interaction, does it? It's going to be an Ajax call or an HTTP GET or POST to a back-end component that does it. In which case, I'd leave the page out of it and start with the back-end component, since (theoretically) the triggering event could come from any page.