I am attempting to understand what UML models/diagrams can be used to communicate a websites architecture.

The model or models' purpose is to communicate the architecture and functionality of a website to technical people (other software developers and engineers).

Website Features:
- The website is a recipe search engine
- Server side code is Python. Client side uses HTML, CSS, JQuery and AJAX.
- The website will have a Web Crawler/Indexer
- Infinite Scrolling is utilised when viewing search results so I will need to model asynchronous requests (both GET and POST).

The diagrams I am tending towards are Component Diagram (to communicate the architecture) and Sequence Diagram (to communicate the functionality of a HTTP request).

What diagrams have you used in the past to communicate the architecture and functionality of a website to technical people?

  • You might want to add an Interaction diagram and data modelling... – LoBS Apr 9 '13 at 0:40
  • As you mentioned the diagrams should communicate functionality, I'd definitely add Case diagrams to those mentioned by @LoBS. It's the best place to start and may show up features that have been either missed out, or are redundant. – TheDarkKnight Apr 26 '13 at 10:56
  • take pen, paper and draw some free form boxes and arrows. Thats the best kind of diagrams in the world. UML was created for snake oil salespeople to impress suit-and-tie guys in leather chairs, and using it for such a simple thing as crawler with web face - is just an overkill. – c69 Aug 20 '13 at 19:43

If you think that UML models and diagrams only serve to communicate the architecture to technical people, you might probably be wrong, since architecture has to be communicated to a lot of other people, especially to those sitting in management with black suits and wanting to have some good reasons why money/time/resource has to be spent in order to realize a specific architecture.

That's also one of the reasons, why UML provides such a large set of different diagrams, which simply aim at different stakeholders with different (technical) knowledge.

Another reason for using different diagrams is simply the complexity of a project. In general you can have static (concerning structures), dynamic (concerning runtime behavior) and allocation (concerning environment mapping) views on a software project. Including them in one diagram would result in a big mess, so you split them up to just have a part of the overall-complexity in one diagram.

Relating to your approach, the component diagram is a static view on the system and the sequence diagram is a dynamic view on the system, so this is quite a good start for documenting architecture.

It's also clear that you don't have the time/money to document each and every possible view/diagram for your system. The consequence is that you have to choose the most important ones, but between which criteria? One the one hand, you have to determine the main kind of complexity in your system. Since web projects have mainly runtime behavior, you would concentrate on the dynamic view of your system. On the other hand, quality attributes like performance or availability play an important role in determining your efforts in documenting, since they are cross-cutting your whole project and therefore cost a lot if you missjudge them.

And as I mentioned above, if black-suited guys hear the cost-bell ringing, they want to get thorough justification and what would in this case be better than having some diagrams in your pocket describing the most complex system-parts with stakeholder-adjusted complexity?

In order to get a general understanding on architecture documentation, I strongly recommend the paper by Philippe Kruchten Architectural Blueprints - The 4+1 View Model After you have read it, it might be much easier for you to determine which models/diagrams you need.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.