![]() ![]() They are used to model software systems during the planning and implementation process or business requirements as part of business process modeling. These types all show the behavior of a modeled system.Īctivity diagrams also have similarities in function with data flow diagrams. They are further categorized as a type of behavior diagram, along with use case diagrams and state machine diagrams. They’re one of the most popular types of UML diagrams because of their similarities with a simple flowchart. And indeed, we can omit the route of node chasing an activity and consider a dataflow node as an activity itself, which starts to work immediately when all its edges (inputs) contain data.An activity diagram is a visual description of the flow of one activity to another as part of a larger system or process. This shows that activity tokens are not different from data tokens. So from simplified point of view, a thread is an activity, and from more rigorous point of view a thread is a data token and the only real activity is a physical processor. This is absolute analogy as tasks are executed on a thread pool. Programmers used to think about threads as activities, but if we look at them closer, we notice that when a thread is ready to execute, it gets in a line to processors, and real execution starts only when a free processor switch to that thread. But generally, both kinds of tokens can be represented in a diagram simultaneously. So both dataflow and activity diagrams are just simplified variants of a general active-data-flow diagram, with either activities or data tokens omitted. This way we can think of activity as a special kind of token. When processing finishes, activity is returned to the queue. As soon as a node meets activity, they both are taken from the queue and actual processing starts. A thread pool is a perfect example of such a queue, and the nodes ready to work are represented as tasks. Typically, the whole node as a token is put in a double-ended queue, where on the other end of that queue free activities (processors or threads) are stored. Usually the process of obtaining that token is omitted, but it has to exist. And to process, it needs an activity token, which represents access to a processor. If we look closer to a dataflow diagram, we can notice that when a node collects data from all its edges, it starts to process them. Just make sure, whatever analysis tool is used, that all aspects of the replacement are documented including workload, I/O, concurrent users, adoption curve, and scalability. My apologies for taking it in that direction. Have you ever wondered why JPMC, Credit Swiss, Walmart, and Bank of America to name a few still run mainframes? ![]() One must weigh the consequences and understand if the replacement can handle workload. We have a CIO who wants to replace all mainframe application for the simple reason that they are old technology. The adage "you break it (or replace it) and you own it" can make you a hero or make you into a clown. Remember that in most cases these are running the business and work pretty darn good. One final comment regarding the age of tools and products. That being said, the better approach is to always practice the story line and answer in simple answers. I have found simple is better and pound-for-pound, DFDs get the message across when I am actually "asked" about details. Just a humble opinion from someone who has had to explain processes, both computer and manual, to upper management and CIOs. But empirically I'd say I find DFDs a more useful tool in ~70-80% of cases. Where control flow is the primary consideration I'll use an AD over a DFD. And hence parallel activity is obvious.ĭon't get me wrong - I'm not against Activity diags. If processes a and b both require data input D then it's obvious on the diagram. Consequently they also make it easier to see causal relationships. They lay bare the real sequence dependencies without any extra effort on the part of the user. Activity diagrams do support concurrency - but it requires the user to (a) remember and (b) use it. Far too often designs over-constrain sequencing. Very useful for consistency and ensuring your thinking is joined up. Data stores on a DFD provide a really nice way to link the data produced / consumed to the object model. Explicit bias: I'm a DFDs is correct that Activity diagrams can be used to represent object flow. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |