Hi Craig,
Thanks for the post. Interesting article on UML shortcomings and a good site on Agile Modelling.
The UML shortcomings he mentions are in user interface, business process/workflow and data modelling.
User interface - the only thing I use in the UML here is a state chart to produce a site map. Each state is a screen and the transitions are the commands available on that screen to go to another screen. We generally create prototypes of each screen which eventually get into the solution.
Business process/workflow - I use activity diagrams. But the best way of showing process I've seen is using Holocentric's XEN Mapper which is their extension of the UML to model process. He made the point that vendors are creating their own solutions where UML isn't good enough. This is one example (see www.holocentric.com usual disclaimer, I'm not associated with them). He also made the point that BPMN is being brought into the OMG fold.
Data modelling - I data model using class diagrams. Have done for 8 years. Works fine. What I'm effectively doing is an ERD using UML notation.
I'm intersted to hear what other people use in the UML to model these. A good start for the original posters project too.
Kimbo
Kimbo:
Data flow diagrams go back to about the mid 60's. However, they were primarily developed to address the short comings of forced-artificial-partitioning-based approaches of which use cases and user stories are classic examples. These other approaches are REALLY old. I mean archeologists found rudiments of use-case-like diagrams etched into the walls of caves that cavemen used to live in.
Tony
A ways back a college professor who is associated with the head of the systems engineering department at MIT told me that they were jointly working on an alternative to the UML. Stated reason: the UML is too complex. My thought: When the folks at MIT say something is too complex, it is TOO complex.
Also, functional AN-AL-LY-SIS is about PAR-TI-TION-ING. (Like Mr Rogers used to say: "Partitioning: Can you say that word? ") Even though analysis is largely about partitioning, with the UML we pretend it does not exist, as there is no UML technique that supports evaluation of such.
Tony old chap,
Probably pointless replying cause I think you mind is pretty closed about UML, but... I disagree with your comments. At a very simple level, DFD's are about data and UML is about behaviour. It is just a different way to look at the same thing. I happen to think that a behavioural approach is much more sensible and a much more 'business' way of approaching things than just looking at data. UML handles the data aspect as well. DFD's don't handle a behavoural approach.
You mention two objections I think. One is about partitioning. It is a nonsense to say that you don't partition in UML or that it is in some way artificial. It is just partitioning from a different approach. In your data / DFD centric world I suppose it may look artificial but if you open your mind a bit you'll see that partitioning using UML is completely valid too. We can partition based on many things, not just data.
Your other objection is about UML being too large. There is nothing that says you have to use the whole thing. I use a very small part of UML that fits into my argument. It works perfectly for myself and my users. The "D" in DFD stands for data and limits your approach to looking at things from a data point of view. The "U" in UML stands for universal and is a brave attempt to provide a language with which to model everything. Data is such a small part of that, so no wonder UML is bigger. Just use the bits you need. You can actually use the UML to build something close to a DFD anyway. But you can use it to do so much more as well.
I suppose I should comment on your MIT guy. I think my full house beats your ace high. There are thousand's of people researching UML, including hopefully the original poster of this thread. You've managed to find one guy trying to make a name for himself. Congratulations but no argument for saying DFD's are somehow better than UML.
I come from many years of using the DFD approach starting in the mid 80's when I bought De Marco's book (its still in my bookshelf somewhere). But you can't hold back progress. Just like programming languages evolve over time, so do analysis approaches. UML is the industry standard at the moment. Get with the program Tone, dinosaurs eventually become extinct!
Liddelk:
Data flow diagrams are used for process modeling, where the process can be either manual or automated. Stated in different terms, for manual systems, they are used to model behavior. With data flow diagrams, the analyst interviews the data to discover essential behavior (processes). This is real basic.
brought to you by enabling practitioners & organizations to achieve their goals using: