Flow Charts

Home | AMDD | Best Practices | Architecture | Requirements | Analysis | Design | Documentation | Models | Modeling Style | Contact Us | Twitter | FAQ
Recently reviewed Flowcharts are a modeling technique introduced in the 1940/50s and popularized for structured development in the 1970s (Gane and Sarson 1979) as well as business modeling. Figure 1 depicts a flowchart for the Enroll in University use case. There are three basic symbols on this flowchart: Squares which represent activities or tasks, diamonds which represent decision points, and arrows which represent flow of control. Flowcharts support other types of symbols, such as off page connectors (for when your diagrams get too big) and input/output symbols to represent printed reports and data storage options. I typically don't use off page connectors as I prefer small flowcharts although I will occasionally model reports (a four sided shape with a curvy bottom edge) and databases (as a cylinder).

Figure 1. Enrolling in the University.

Notice the differences between the flowchart and the data flow diagram (DFD) which also models this use case. Unlike DFDs which are used to describe data flow within a system, flow charts are typically used to describe the detailed logic of a business process or business rule. In the past it was quite common to use flow charts to model the logic of large software modules, such as a 30,000 line COBOL program. However, because object methods are much smaller (a 30 line method would be considered quite large) flowcharts have dropped out of favor with programmers in recent years. That's okay, they're still useful for process modeling. It is important to note that although the flowchart is much more detailed than the DFD I could just as easily gone to the same level of detail in both diagrams.

To create this diagram I simply worked through the business logic a step at a time. I started at the top left corner of the board, you can see the arrow coming from nowhere into the side of the Distribute Forms to Student step. It's interesting to note that the use case doesn't specifically call this out as the first step, but it does seem to be implied and this step is required if the registrar determines that the forms aren't valid.

Each time a decision is made I introduced diamond. In this example all the decision points were yes/no questions but that doesn't always have to be the case. I could just as easily ask a question such as "What is the day of the week?" and had seven arrows leaving the diamond, one for each day. Each arrowhead leaving a decision should be labeled with the appropriate condition but as you can see I forgot to label the yes arrow coming out of the Valid diamond - remember, agile models just need to be just barely good enough.

It's interesting that by drawing this flow chart I seem to have picked up some logic errors in my use case. First, the box with a question mark in it indicates that I still need to think through an alternate course in the use case, no big deal. The real logic problem is that I check to see whether the person exists in the database before I check to see if they're on the list of expected applicants. This doesn't feel right to me so this is something I should discuss with my stakeholders, pointing out the value of AM's Active Stakeholder Participation practice - if the stakeholder is working with me on this model we can resolve this issue right away, if not then I have to either wait for them to be available to discuss the issue or simply make something up on the spot and risk having to fix it later on.

The best way to stay agile when working with flow charts is to keep things simple. Sketch them on whiteboards with your stakeholders to discuss important business logic, take a digital photo if you want to save it, or simply erase it once you're through. The value often isn't in the models that you create but instead it is in the act of modeling because it helps you to think things through. For example, the flow chart of Figure 1 has helped my team to identify a potential problem with our use case, but once we've fixed that problem the flowchart isn't going to be of much value any more.

I don't use flowcharts much any more because I prefer to use UML activity diagrams instead, and in fact activity diagrams are arguably sophisticated flow charts (there's more to them than this though). Regardless, I it's important to be aware of flow charts because you will still see them used by experienced IT professionals from time to time.

Source

This artifact description is excerpted from Chapter 9 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.


Translations