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 kommentar(er)
