Context Diagram

A context diagram is a data flow diagram, with only one massive central process that subsumes everything inside the scope of the system. It shows how the system will receive and send data flows to the external entities involved. Here's a theoretical example:

And Data Flow Diagrams are ?

Data flow diagrams, in their simplest form, show that a data flow occurs -- somehow, sometimes, for whatever reason. They don't show when it occurs, or under which circumstances, or using which medium. Like an X-ray, the data flow diagram focuses only on a few important essentials. At a level of granularity where there's a danger of entirely overlooking a data flow, a data flow diagram is a good start.

Data Flow Diagramming Methodology

Two common symbol sets are used in data flow diagramming: Gane-Sarson and YourdonDe Marco. Both provide adequate means of expressing the concepts. Please, please don't try to invent yet one more methodology: requirements engineering is already confusing enough. The following diagram shows a Gane-Sarson example, to indicate that Person A communicates the customer name, and the agents then store it in the customer file:

The following diagram shows a Yourdon-DeMarco example:

Symbols Used on Diagrams

At PQS, we happen to use Gane-Sarson symbology. As such:

processes are shown as squares with rounded corners (which in this example happen to be colored red)

external entities (the people with whom the process interacts) are shown as squares (which in this example happen to be colored blue)

data stores are shown as elongated, flat rectangles (which in this example happen to be colored green)

data flows are shown as arrows

The agents or operators who perform the work are considered "inside the process," and as such are not shown. Fortunately, for context diagrams, you don't have to worry about data stores. They're considered internal to the process.

Example Context Diagram. The components of a context diagram are clearly shown on this page. The system under investigation is represented as a single process, connected to external entities by data flows and resource flows. The context diagram clearly shows the interfaces between the system under investigation and the external entities with which it communicates. Therefore, whilst it is often conceptually trivial, a context diagram serves to focus attention on the system boundary and can help in clarifying the precise scope of the analysis.

Stepwise Diagram Evolution. Draw and name a single process box that represents the entire system.

Next, identify and add the external entities that communicate directly with the process box. Do this by considering origin and destination of the resource flows and data flows. Finally, add the resource flows and data flows to the diagram. In drawing the context diagram you should only be concerned with the most important information flows. These will be associated with how orders are received and checked, with providing good customer service and with the paying of invoices. Remember that no business process diagram is the definitive solution; there is no absolute right or wrong. The shop manager and staff do not appear as entities at this level; as both occur within the system process box. Several points could be debated. For example, should the resource flow 'Product' be two way in both cases, allowing the return of faulty goods? You will need to make numerous decisions like this as you develop a business model.

ACTIVITY DIAGRAMS

The activity diagram focuses on activities, chunks of process that may or may not correspond to methods or member functions, and the sequencing of these activities. In this sense it is like a flow chart. It differs, however, from a flow chart in that it explicitly supports parallel activities and their synchronization. In the diagram we see the receive order activity triggers both the authorize payment and the check line item activities. Indeed the check line item is triggered for each line item on the order. Thus if an order has three line items the receive order activity would trigger four activities in parallel, leading (at least conceptually) to four separate threads. These threads, together with other threads started by the receive supplies activity, are synchronized before the order is dispatched.

Note that this diagram does not have an end point. This is typical of activity diagrams that define a business process which synchronizes several external incoming events. You can think of the diagram of defining the reaction to that process, which continues until everything that needs to be done is done. You can also draw activity diagrams with a single start and end point; such procedural diagrams are more like the conventional procedure invocations. Such procedural diagrams can also use parallel behavior. The biggest disadvantage of activity diagrams is that they do not make explicit which objects execute which activities, and the way that the messaging works between them. You can label each activity with the responsible object, but that does not make the interactions between the objects clear (that's when you need to use an interaction diagram). Often it is useful to draw an activity diagram early on in the modeling of a process, to help you understand the overall process. Then you can use interaction diagrams to help you allocate activities to classes.

When to Use Them

Activity diagrams are useful when you want to describe a behavior which is parallel, or when you want to show how behaviors in several use-cases interact. Use interaction diagrams when you want to show how objects collaborate to implement an activity diagram. Use a state transition diagram to show how one object changes during its lifetime.