Coincidences are strange things. As a result of one such, this note sets out some thoughts on process models.
A recent email from a previous examination candidate included the comment “My understanding is that UML Activity diagrams cover Process Models”.
By chance, the issue of UML and process modelling had come up just a couple of weeks previously, specifically in the context of Requirements Engineering. Without going into detail the concern was whether, in RE, a swimlane diagram could be used to document a process. Put another way, would a swimlane diagram be an appropriate technique for modelling a process or would a Use Case be more correct.
A part of the reason behind the question was that swimlanes are seen by some exam candidates as relevant only in the context of the Modelling Business Processes syllabus. There they are used to model business processes. When it gets to modelling requirements people tend to think of UML, and specifically Use Cases for processes.
This got me thinking about models and the question of the ‘correct’ notation to use and why people think a particular style of notation is or is not appropriate.
The syllabuses for RE and MBP each talk of modelling processes – business processes in MBP and system processes in RE. We can argue the semantics but really each is asking simply for a model of a process. As one author put it, a process, is a process, is a process. There is no difference between a process when modelling a business process and when modelling a requirement, they are processes, pure and simple. The only difference is the context in which we are seeing the processes and the level of detail required, and this is why we may choose to use one notation rather than another.
If we are just distinguishing requirements (processes) from each other we may decide that a Use Case diagram is a good notation. If we need to see more detail then we might develop a list of steps (a Use Case description) or we may take on board the following quote from the third edition of Business Analysis:
The detail of any processing carried out within the use case may be documented using a variety of techniques. For example, we could use activity diagrams from the UML or other more established techniques such as decision tables.
Or, from Martin Fowler’s UML Distilled:
An activity diagram can show the context for use cases and also the detail of how a complicated use case works.
But an Activity Diagram is remarkably similar to a swimlane diagram, particularly when partitioned and the ‘actors’ are added to it. So, an activity diagram, or swimlane, can be used to model a process.
Neither the RE nor MBP syllabus prescribes a particular notation. In real life one would be guided by the standards of the employer. If the organisation uses a standard set of notations then that is what we would be expected to apply.
For examinations, the exam providers recognise this diversity and will always give credit where candidates apply a relevant notation. Examiners are not out to catch candidates and will never say that there is only one valid style. Even so it is for the candidate to read the question and assess the best approach.
So the conclusion is that Activity Diagrams are process models and that swimlanes have a place in the RE syllabus.
If that has resolved one area of discussion then let me point readers to another article related to RE.
The RE syllabus expects that candidates will be able to ‘interpret a model of the data requirements for an information system’. My colleague Keith Gordon has posted a description of data model notation and you will find this by clicking the link. This is a must-read for an RE candidate.