What is the practical difference between using flowchart diagrams and UML activity diagrams?
I have some thoughts, but maybe I'm missing an elephant in the room?
Flowchart diagram:
Widely used;
Easily understood by non-programmers;
Old?
UML Activity diagram:
Standardized;
Supports concurrency;
Less known syntax, but still simple enough.
For my case of ad-hoc documenting a particular block of application logic, I decided to go with the flowchart diagrams. More people in the company will be able to understand them.
It might seem as a preference, but if we have a standardized language for describing software systems, Why do we use something else? This can lead to bad habit of overusing flowcharts. Activity diagrams are really simple. But if you decide to describe a more complicated aspect of the system or try to change the part you are describing, you might have to switch anyway. So just use UML and prevent confusion in the future.
As you note, Activity diagrams inherently can include concurrency and timing. If you look at this example cribbed from Wikipedia, shown below, you can observe the section with two heavy horizontal bars, and two parallel activities of "present idea" and "record idea". That is read as "start these activities in parallel, and continue only when both are complete." Flowcharts can't express this within the notation.
Practically, using activity diagrams lets you think clearly about concurrent processes. I think you'll find that anyone who can read a flowchart will quickly adapt.
Activity diagram by ​spanish Wikipedia user Gwaur CC BY-SA 3.0, via Wikimedia Commons:
According to the Agile Modeling site:
In many ways UML activity diagrams are the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development.
From IBM:
However, flow charts do not include And states, and flow charts for operations cannot receive events.
Probably this is why flow charts are easier to understand because activity diagrams have the notion of object-oriented development and concurrency.
You can generate source code from UML, and vice versa; hence the "standardized" characteristic you talked about.
UML in itself is used to share your understanding. Share the understanding in a standardized way. Since your case is ad hoc and the primary usage of an UML diagram is to provide an informal sketch, activity diagram can be used here. But so can flow charts as there are no parellism involved here. I have always found the following argument to be helpful. The artifct that i am producing is going to benefit whom? And can i express the flow in a self explanatory way using a flow chart. And if yes, then you should go ahead and use flow chart. But if your class diagrams, sequence etc are in UML format, it would make sense to have your activity diagrams in UML as well for consistency sake(The argument here would be, if people can understand class,sequence UML semantics, then y not activity diagrams.).
Related
I know that an activity diagram is:
More simple;
More standardized;
Support concurrent flows.
compared to a flow chart.
But what are the possible reasons for using an activity diagram instead of a flow chart apart from those mentioned above?
An activity diagram is not simpler than a flow chart. A flow chart is a simpler (earlier) version of an Activity Diagram.
Flow charts were invented at least 20 years earlier and are commonly used by non-programmers to document workflows. Any business process where people have to make decisions can be described as a flow chart. So, for example, a clerk making decisions about how to file complicated information might have a flow chart on the wall.
Because a flow chart is a subset of an activity diagram, there's actually no decision to make. A flow chart naturally grows into an activity diagram if you need to add more complex descriptions.
Sparx have a good explanation of the range of things you can describe in an Activity Diagram
A UML Activity Diagram is a type of "flowchart" .. in UML, with bells and whistles. There is no such thing as a "UML Flowchart". If using UML it is an Activity Diagram. If using something else, then something else is being used.
[UML] Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency ..
.. Activity diagrams may be regarded as a form of flowchart.
For better or worse, UML is a standardization. This is nice because it is well, "standardized", but also means that it is not appropriate for all tasks: the chosen "flowchart" model (and extensions thereof) might be a better fit for a particular problem/domain.
An activity diagram assigns responsibilities to the objects involved in collaboration using swim lanes. So the diagram clearly shows the work to be done by each object in collaboration.
Please help me know as to when it(uml) is necessary. I was told that generally UML are drawn for web based application developement, for desktop based, DFDs and ERDs are used. My university requires all the diagram(uml,dfd,er). please let me know if my information is correct? Thank you
UML Diagram are imporant because it help the person to understand the relationship and dependency between different class present in the code(Class Diagram).
Flow of the program(Sequence Diagram , Activity Diagram).
Help to improve the program architecture etc.
And read about different type of UML diagram you will get more information.
Your needs in using UML depends on your position and your (self)education.
Some companies use UML. So, you would need it to get a job in them. Just now your university requires UML diagrams, so there IS a need in them, isn't it?
If you know UML a bit, you could understand the thoughts of your colleague who wants to share them with you this way.
If you understand the language of a UML diagram, you can use it for improvement of your thinking on the problem. So, you can think into the problem deeper and faster than without a tool. You should be really well acquainted with the tool though, for when inventing something new, you need to think on the domain problem, not on the language problems. But you don't need to know all the rules for this level of use yet.
If you know UML so that you can draw diagrams up to their strict rules, you have two more uses of it.
Translating your knowledge of the problem from one level of abstraction to another and modelling these levels up to the strict rules, you are filtering many misunderstandings in the already accepted model and can practically debug the model before coding. It can save much time and money.
While you are making the diagrams according to strict rules, you can collaborate on the model with your colleagues. It is always better if you can express your ideas more precisely.
As for technology limitations, you can use UML very widely, even out of the IT needs. As for IT, only GUI creation is supported badly. And anonymous classes are almost not supported in class diagrams at all (in behaviour diagrams they work OK).
DFD (datya flow diagram) and ERD (entity relationship diagram) diagram are tools for structural analysis and design, this is way to build structural application (data bases and functions). UML support quite different paradigm: object paradigm - we build application as collaborating objects. DFD and ER (ERD) diagram is not part of UML. We can use ER diagram for data base modeling and join to UML domain model by the ORM (object-relational mapping, implemented e.g. by Hibernate).
I am not a big fan of UML. I believe UML is great in some rare instances, however I do not want to use a UML diagram to show a high level flow of calls through my application. Problem is - most of the tools (visio, lucidchart, websequencediagrams) force the user to either draw a very detailed UML diagram, or a sequence diagram. There is nothing that would be like a high-level version of a UML diagram. Or is there?
There is no such thing as a "higher level" UML diagram. UML has 12 (or was it 12? I can't remember) and you must choose from one of them, the best that fits your needs.
For a high level flow of calls I like activity diagrams, even though the objects that own the functions are harder to see. Sequence diagrams are a waste of time and space IMHO .
Back in the Dark Ages (mid-1980s), I used Data Flow Diagrams from Structured Analysis a fair amount, and found them very useful.
My current employer loves UML. I normally use BOUML, which doesn't do non-UML drawings.
What is the UML drawing that corresponds to the Data Flow Diagram?
If there isn't one, what is the recommended UML diagram to present the corresponding data?
Probably the closest thing is the activity diagram. It's not quite the same; more influenced by flow chart than dfd. However: you can do some of the useful things in DFDs, e.g. ADs do support concurrency and differentiate control flow from dataflow.
More details on comparisons & differences in this question.
[fwiw, I still use DFDs: they're simpler and more elegant in many circumstances]
hth.
UML 2 has a very good analogue to a data flow diagram:
the "information flow diagram".
Information flow diagrams are explained here:
https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
Note that UML 2.5 has information flows and information items, but the term "information flow diagram" is not part of official UML 2.5 diagram taxonomy. So formally, you just create a class or component diagram with lots of information flows in it to obtain your "information flow diagram".
I do this all the time, using information items of UML to represent my data.
There is no equivalent model in OOD. The emphasis on DFD's is data separated from the function. This is most helpful when dealing in a procedural way. DFD's scale much better than OOD, if you try to scale out (to the world view) using OOD you end up using Use Case diagrams, which are useful for capturing essences. I loved DFD's they are so high level, and yet can be expanded by opening up a DFD box and calling it level 1 etc.
I am currently in the process of learning the Go programming language, this does not use Objects whatsoever and in some respects I feel that DFD modelling would suit it much better.
I too am looking for a diagram that could do this sort of work. In Go structs are used intensively which are basic data types. You can have a primitive extension method attached to it which resembles OO but in fact if you look at the Assembly code it appears to be syntax sugar for a function, who's first parameter is the struct you wish the function to operate on.
My advice, is that if you're doing OO code, then use OOD. They map better, and do help in the thinking about a system. It takes a while to get your head out of Procedural code, especially if you're coming from programming from the 80's/90's. Once you're in the zone with thinking about objects then the OOD methods work fine. Its not strictly a methodology as there is no straight answer to which parts you use, just thinking in objects I find to be the hardest part. A good book on this is "Object Thinking--David West"...it helps to think about objects first. Once you start its very difficult to stop, you may even like some end up getting trapped in the kingdom of the nouns which is a horrible place to be, because you write endless boiler plate code, just so that the system is described perfectly. This is a form of coding hell which I have stayed clear of for many years.
If you are coding in a language that allows procedural code, or even mixed OO/Procedural, you need to decide your paradigm before you start coding, for example in both Python and Object Pascal (Delphi) you can go either route of OO or procedural coding mixing the code up into a mess of paradigms. This will decide which diagramming tools that should be used, and how you are going to analyze the system.
Recently there have been shifts in Java and c# to provide functional programming techniques. These I have discovered don't fall into either category of programming (OO or procedural). Trying to map functional programming code into an object is a nightmare.
I am sorry I haven't provided an answer, but it depends on what code you are writing.
There is no direct analogue, since UML emphasises OO design wheras DFD comes from structured systems analysis and design (SSAD). In UML a number of diagrams, specifically those in the with interaction diagrams group have characteristics that might model elements of data flow and processing. A Communication Diagram can be used to reflect most aspects of a DFD in general, while a sequence diagram may model specific sequences of flow. If you wanted to suggest DFD semantics then you could use stereotyped objects for data process and data store, and use actors for external entities.
It may be worth noting that Sparx Systems Enterprise Architect, while primarily a UML tool includes DFD as an extension.
Similar diagrams would be:
information flow diagram
communication diagram
sequence diagram
Theoretically, new diagram kinds can be defined in UML, optionally extending of one or more conventional diagram kinds. The canonical diagram kinds defined in UML are essentially defined as a part of the UML metamodel itself.
Formally, a definition of the UML metamodel is provided in the UML specification published by the Object Management Group (OMG), as well as the corresponding meta-metamodel defined of MOF - to which there is also a corresponding specification - moreover as accompanied with the formal OCL specification, as with regards to definitions of constraints in UML models in applications of the OCL language in UML - and then there's the XMI specification, as with regards to specifications for how UML models may be stored in machine-readable format.
Ostensibly, all of these specifications may be combined for application as though "Under the hood" of any single framework for UML modeling - whether in applications of the Ecore subset of the UML metmodel, or in canonical UML.
Reviewing a short academic presentation about Data Flow Diagrams -although somewhat in departing from formal definitions of UML diagram kinds, but nonetheless in a broader context of applications of the MOF meta-metamodel - perhaps the canonical BPMN metamodel - in its conventional, graphical abstract syntax - perhaps BPMN may serve to provide something of an analogy to Data Flow Diagrams?
Of course, modeling practices may vary by vendor and by application environment.
I consider a Data Flow Diagram as a Sequence Diagram, with Data Producers and Data Consumers creating, using and destroying Data objects by means of synchronous and/or asynchronous messages.
I use Enterprise Architect 'Dynamic View' Analysis diagram.
Control = Process
Information = Data Store
In many ways their Analysis diagram is much better than a data flow diagram, as you can also show events in the form of sending and receiving and there is a process symbol too but I prefer Control. It includes object and decision.
I'm fond of using UML diagrams to describe my software. In the majority of cases the diagrams are for my own use and I use them for more involved pieces of code, interactions etc. where I'll benefit from being able to look back over them in the future.
One thing I've found myself doing a few different ways is diagramming threads. Threads by their nature tend to pop up in the more involved pieces of code and keeping track of them is often a primary purpose of my design documents.
In the past I've used a symbol in a sequence diagram to show the creation of a new thread but looking back at some diagrams doing that it's sometimes ambiguous between an object's lifetime - which sequence diagrams are for - and a thread's lifetime. Is there a better approach for incorporating threads into UML?
I managed to produce a diagram that makes sense to me at the time of drawing it. The basic premise is that I've overlaid grey boxes representing class instances with blue boxes representing thread lifetimes. The main thing it lets me keep track of is knowing which thread I will be executing on when I call certain methods.
No doubt there's better and more intuitive ways to do thread and class modeling. The measure of success for me is whether my own diagram still gives me the same level of understanding 6 months down the track.
Activity, Sequence, and State Diagrams are all correct ways of showing thread behavior.
1st: (To vs's comments) There are two sets of diagrams or modeling elements in UML, static structure, as you put it, and behavioral. Any book will help you understand the split, typically in the contents/TOC, additionally it can be seen on page 11 of Martin Fowler's UML Distilled a near defacto standard for beginning UML in my opinion.
2nd: (To sipwiz's question and comment) Activity diagrams are not commonly understood to model business process, they can be used for that however, and most examples or simple tutorial would approach it from a business standpoint.
Discussion on your options to model threads:
Activity diagrams - Allows for forking and specifying concurrency by using a BAR and usage lines. Note the example at the bottom is no a business process, example. Most people can read these, business, management, and developers, though sometimes they can lack detail or get messy.
Sequence Interaction diagrams - In the same post, example, you will see sequence diagrams allow you to specify parallel behavior within a sequence by boxing parallelizable behavior with a label "par", this is useful to show the reader what methods can or should be called in parallel, ie, by different threads. This is the method I would use for detailed developer like discussions around building an object.
State diagram - The state chart just like the activity allows for concurrency by using a BAR and usage lines.
NOTE: These will not model a specific thread and it's exact lift cycle, as that is part of the instance/run-time level of modeling, if this what you want clarify your question and I will respond. I would just model it using one of the above as no one other than a MDA/UML expert will call you out, and you are not generating a running system.
Also: Please note that further details can be found in most UML books.
Also leveraged: http://www.jguru.com/faq/view.jsp?EID=56322
Traditionally threading has been depicted diagramatically using Petri Nets. Rob Martin has an article on multithreading in UML which you may find useful.
Update- just remembered you can represent threads with forks in activity diagrams- I've managed to find something that explains this.
It is very hard to find any free tutorials for Petri Nets, however I know Petri Nets are good for modeling concurrency, so I Google'd "producer-consumer Petri Nets" (my favourite threading thing) and found this.
I've also found some slides that show Petri Nets modeling a Semaphore.
UML activity diagrams have fork and join elements to show parallel flow of logic.
I don't know of a way, but using a sequence diagram does not seem entirely inappropriate, considering that a thread is in many languages implemented as a Thread (or similar) class.
The most UML-compatible way would probably be to add an annotation of some sort indicating that the 'object' represents a thread.
The UML is defined by the UML Superstructure, you can find it here http://www.omg.org/spec/UML.
If you read the specification you find that a UML class can be active. An Active Class is a class with the meta-attribute isActive set to true. It is also depicted differently.
An object instances of an active class automatically executes a "classifier behavior". As for any behavior you can define it by means of an activity in which you wait for asynchronous signals (AcceptEventActions) and invokes methods (CallOperationAction) or other behaviors (CallBehaviorActions). That is how active objects are modeled in UML. You just have to read the UML specification.
Activity diagrams will model the internal workings of your software with forks and joins to represent threads. To find out exactly how to model this properly, please see Conrad Bock's excellent series of articles. Here is the article that covers forks and joins, but you should follow the links back to the first article in the series to learn how to properly model using "Colored Petri Nets". It's not how you think (and it's pretty easy)!
There is a new, in-process standard at the OMG for a language called Alf that provides a more convenient surface notation for activity diagrams and is intended for representing code. From the spec:
A primary goal of an action language is to act as the surface notation for specifying executable
behaviors within a wider model that is primarily represented using the usual graphical notations of
UML. For example, this might include methods on the operations of classes or transition effect
behaviors on state machines.
For a programmer, you probably can't get more intuitive than Alf. And it will convert perfectly into UML activity diagrams.
UML strongest point is depicting the static structure. If you use short-lived threads, I also don't see any easy way of diagramming them. Maybe you can find a solution by turning things around a bit: why do you use/need threads? What's the functionality they provide? If they interact with each other and follow some (message passing) API, drawing them as components might make sense.