I'm drawing a communication diagram for an application where you can buy books. I'm using domain-driven design and have a 'shop' object, a 'cart' object, and a 'book' object.
My first communication diagram, for when the user first comes to the site, is straightforward. I generate all HTML (to show all books and an empty cart) back end with the help of PHP. I use an MVC pattern; so first I send a message to a 'controller' which creates a 'shop' with 'book's and an empty 'cart' before sending these to the view.
My second communication diagram is where I run into problem: It is about adding a book from the shop to the cart. I already have all the information I need to add the book to the 'cart' on the client side; since all book information is already in the shop. So when writing the communication diagram, should my first message, that is, AddBookToCart(bookId:int), be to a JavaScript object called 'shop' which gets the book info and send a message 'AddBookToCart(bookinfo:object) to 'cart' which in turn update the page?
I have never done communication diagrams with JavaScript in mind before, so I'm really confused about how to deal with the front end.
(I have been searching for over five hours, but I didn't find anything on this topic. It's like it's not even an issue to people. Am I viewing this problem completely wrong? Otherwise any resources, or even search terms to use to learn about how to model (and code) these kind of things would be much appreciated)
Best Answer
Given the uncertainty of my answer, I make it a community wiki. Feel free to edit it.
It depends on the abstraction level you use. One way is to be language-agnostic. Here's an example of a sequence diagram:
Source: UML Sequence Diagrams Examples
As you can see, the diagram encompasses both client-side and server-side. Applying the same to a communication diagram would be harder, since communication diagrams have generally a smaller scope, but it's still possible.
The major factor to take in account is what is the purpose of your communication diagram.
One possibility is to use a communication diagram to show the entire process. Such diagram may be language-agnostic and mix several parts of the system or layers within it.
This is suited well for an overall view of a system in a highly abstract way. It may be used, for example, to give a general idea to a new developer of some complicated stuff which happens between a client and a service, between JavaScript and server-side language or between a consumer and its API.
If your company has a single developer who does both client and server-side programming, then such diagram may be useful to him.
Another possibility is to use a communication diagram to show precise flow within a layer of a part of a system. Here, other parts and layers would be interpreted as black boxes which communicate through interfaces.
This is suited well for a detailed view of communications flow within a system. For example, a JavaScript developer cares about communications flow happening in the browser, but doesn't care about server-side stuff. In the same way, a developer of an API won't need to look at the communications diagram which explains how a client of the API is dealing with the different messages.
If your company has dedicated client-side programmers and dedicated server-side programmers, they would probably favor this sort of communication diagrams (which doesn't exclude that they should also have a good overall view of the whole system.)
In practice, I've never seen communication diagrams so general that they would encompass for example both client and server-side. I don't think it's wrong to do such diagrams, but it's not a common practice.
Edit: I talked with a colleague more experienced than I in UML; his suggestion is to create two communication diagrams, one for JavaScript, another one for server-side. Mixing both would make the diagram more complicate than it needs to be, and some people may not understand which step is happening where.
So unless you are sure that having a single diagram would benefit you, stick with separate diagrams that you can put side by side for an overall view.