What's your experience with the use of UML activity diagrams in the software development process? How and when were they most useful for you? Or don't you think they are very useful and why not? Should they be taught in any self-respecting software engineering course or project? How do you or did you use them on your own projects and how did you experience their value? Were they a big help or just an interesting but non essential modelling notation?
From my experience, I have seen few projects that are developing activity diagrams. In most cases, you see projects focusing on use cases, sequence diagrams, and class diagrams which can be quite complex. I am not sure about agile software projects if they find them useful. But personally I do think they can be excluded from your project without losing much of information.
Actually I know that Activity diagram is only use for Business point of view and more over activity diagram is not required in all the cases of software design rather than Use Case diagram.
I know that activity diagrams can be used to define business workflows or processes, but I was more thinking of using activity diagrams to provide a high-level view of the behavior and flow of the software system to be developed, as a sequence of actions, as in the image attached below (taken from http://www.tutorialspoint.com). Such an activity diagram seems like a useful notation to present the overall flow between the different actions to be performed by a system. (And to get feedback from the user whether this is indeed the intended or desired flow that the application should implement.) I would thus use them more during the requirements phase, whereas for the analysis and design phase, maybe sequence diagrams may be more appropriate to describe the detailed behavior of the system.
I know that uses cases could also be a way for modeling the functional requirements of a software system at a finer-grained level (per use case scenario), but frankly speaking I never really liked use cases, they somehow don't seem to work for me. Then I would prefer user stories over use cases.
An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operation. Because an activity diagram is a special kind of statechart diagram, it uses some of the same modelling conventions
From my experience, I've used activity diagram along with other UML diagrams for modeling the behavioral pattern i.e. the system dynamics. I think through the use of activity transitions, branching, forking & joining, swimlanes and objects' flow in the activity diagram, you can effectively use it to model the workflow and operation of the system. So, I think it should taught in the university courses under the name of OOAD, SE or other like these, not just the data flow diagrams (DFDs). You can find the usefulness of this diagram in the book "The Unified Modeling Language User Guide" by Booch, Rumbaugh & Jacobson. Regarding to the Agile software development methodologies, I've experienced it to be useful while modifying the dynamic system model in different iterations especially in my Scrum practice.
In my practice, every use case diagram has an activity diagram attached to it to describe the workflow of that use case. A sequence diagram would also be suitable for that purpose, but I believe an activity diagram is the better choice since it allows better alignment with business process models, wich are usually also drawn in the activity diagram or BPML notation.
These use-case activity diagrams can then later be used in the design and verification process to derive interface items and testcases.
I've used AD to describe use cases interactions and explain the flow of some process or user-system interactions. I believe that visual interpretation becomes easy for anybody that have worked with data flow diagrams.
As any other diagram type in UML, activity diagrams have their role in the modelling of a system. Not all systems need all diagrams, but in the particular case of activity diagrams, I feel that it is in part caused by a lack of knowledge about these diagrams by developers.
In my (quite long) experience in system modeling, I have found a surprisingly high number of developers that believed that a UML model is a class diagram, and a surprisingly high of developers that created diagrams using their own rules and semantics, thus ruining the original goal of UML of becoming the standard modeling language.
Going back to activity diagrams, we have found them to be very useful for describing processes.
I use the Activity diagrams for modeling the business process. I think It's the best way to understand the flow of information and who is responsible for it.
Activity diagrams can be useful in the development process to express and discuss behavior. This is especially helpful in embedded systems, protocol interpretations, and workflows or processes. We use it mostly as an informal notation.
Depending on the domain, they can also be "prototypes" of formal workflow or process descriptions. We have used them in my last research project as a visualisation of processes written in a DSL. And I used it to illustrate them to discuss the behavior of a monitoring aggregator with adaptive monitoring (see link on Kieker Data Bridge).
http://www.oiloftrop.de/code-research/proposal-kieker-data-bridge-and-adaptive-monitoring/
- Badges
- Science topic
- Similar topics
- Mathematical Sciences
- Graphs