Heal Your Church WebSite

Teaching, rebuking, correcting & training in righteous web design.

UML diagramming for fun and prophet

Aim for nothing and you’ll surely hit it – and aphorism that is as true for software as it is life in general. So why do our church websites suck? In part because we don’t know to speak the language of software design. Below are some links to some simple tutorials for the object oriented modeling language known industry-wide as UML.
“Therefore I do not run like a man running aimlessly; I do not fight like a man beating the air.” – I Cor. 9:26

There is an old Baptist aphorism that goes “aim for nothing and you’ll surely hit it.” Not only is this true for one’s spiritual life, but it goes for software as well. I mean, imagine building a house without a blueprint? Yet that’s what we do all too often — in part because we don’t know to speak the language of software design.

Below are some links to some very simple tutorials that attempt to translate a very complex object oriented modeling methodology otherwise known as the Unified Modeling Language — or UML as it is known industry-wide.

Learning UML may be a bit of overkill for your church website, but my intent here isn’t for you to become an anal-retentive software analyst. Rather it is to get you thinking about diagramming your church websites design, layout and interaction. Specifically, I need you to think about the sequence of events, how users interact with your system and how data is stored and delivered.

Without doing this, at any level will lead to me visiting your website and picking it apart because you didn’t bother to measure twice before cutting … you’ve been warned:

Short and Sweet:
SmartDraw UML Center – How to Draw UML Diagrams in both the handy online HTML version, and the ‘print-it-later for the “reading-room” PDF’ flavor.

Extended Reading
Let’s say your rock-n-roll band has a long bus trip from Frogger, Virginia to Lizard Lick, North Carolina. Fear not! Developer.com has produced a nice sequential series of articles on the topic that are as fun to read as they are to eat. For your convenience, I’ve enumerated them below ordinally:

  1. UML Overview – What is it? Why do I need it? What about my needs?
  2. So you want to spend some money on some UML Tools? HA! Well th ink again, some are free (as beer).
  3. Creating Use Case Diagrams – Identifying the primary elements.
  4. The UML Class Diagram: Part 1 – Breaking down into its smallest parts.
  5. The UML Class Diagram: Part II – Practical examples.
  6. Object Diagrams in UML – Piecing the individual classes together into a single system.
  7. State Diagram in UML – Flagging when interactions happen, even when they don’t.
  8. Activity Diagram in UML – Let’s get busy people. Put them objects to work.
  9. Sequence Diagram in UML – If you read this, then ‘x’ will happen. Get it?
  10. Collaboration Diagram in UML – Can’t we all just get along?
  11. Component Diagrams in UML – Better programming through reusability.

Finally, massive mea-culprits for not writing sooner. The new job has kept me VERY busy. That and the fact that my wife and kid are still in MD getting the house packed up, it’s been a bit tough. Pray for me — and my broken foot.

Now go learn how to design stuff.


  1. Thanks Dean…I think. Actually planning a website, what a novel idea, anyway my prayers go out to you and your family.

    I love the idea of diagramming a site, but this seems way over my head. Is there a simple example somewhere I could look at?

  2. Good stuff, Dean. I’ve read a lot on UML diagrams but haven’t used them too much.

    Use cases on the other hand are very practical for accomplishing goals on a website. However, I’ve found that essentially use cases are text based and use case diagrams only complicate things. Martin Fowler came to the same conclusion in his excellent, concise book on UML, UML Distilled.

    Check out some great examples of text based use cases from Alistair Cockburn’s book, Writing Effective Use Cases:

    PDF Pages 23-25 of 113

  3. I run a website of about 2000 pages. I think UML is more or less a waste of time. It’s nice theory, but in practice it just makes things more complex than they need to be. Great for web consultants though, helps keep up the high hourly fees.

  4. Oy. Some pretty complex diagrams there. Makes me wonder about software vs. websites. Sometimes they look the same…other times not. I think in this case I’d have to side with Andrew, even though I’m one of those web consultants with “high hourly fees”…;)

    I’m in the middle of a fairly complex project, with a public web component, affiliate web components, and back-end administrative components both web and desktop based. In order to document this project we started with a functional spec that purely outlined what the “application” had to do at a task level for each audience involved. From there we put together a site map, then wireframed out the entire site. Then I wrote some high level “use narratives” (not going into the detail of the Alistar book mentioned above).

    I think the question, with all of these spec. docs is “what’s the purpose?”. On this specific project the fun spec served to give a basis to quote the development. The sitemap was only put together to drive the wireframes (sitemap not shown to client). The wireframes were put together to visually demonstrate the architecture and some significant changes we were proposing, then they were used to determine the number of unique templates or page types the designers needed to create. The use narratives served to put the human side to the functional spec for the developers to understand how the application was to get used.

    Even though this is one of the more complex apps I’ve been involved in lately, I don’t think UML would have brought anything to the table. The developers have a good grasp on the tasks at hand, the quote was generated and accepted by the client. The proposed architecture was accepted by the client, and the designers had a good starting point for design.

    From what I know of UML, I’d expect to see it more in use at the mission critical enterprise level software development level, where any downtime is costing mucho bucks.

    For most websites? Not sure I see the value.

  5. Pingback: 0d4ecb5