I don't get UML designers. They skipped in UML very useful design tool: data flow diagrams (DFD) and placed cheap substitute called "activity diagram". Why? Because data flow is not object oriented (no encapsulation). Should we skip this useful tool and use only diagrams defined by UML? I don't think so.
On the other hand general problem with DFD (and any diagramming technique) is scalability. If you want to express many flows using DFD you have to make DFD hierarchical, thus overall picture may be hidden here. If you place too many (>9 items) details on one diagram you are lost again.
There's simple and very powerful, but forgotten technique called "CRUD tables". What's "CRUD"? It's a table (can be implemented by a spreadsheet) that for every process in a system defines it's interactions with main entities: Create, Read, Update, Delete. CRUD table was used mainly during database design, but I think this technique can be used for every data flow in a system (including external actors and entities).
I'll show you how you can utilize CRUD table to make initial design and get software complexity estimation.
First of all, a specification:I need to sell products on my website. I'd like an order is created in my ERP system just after instant payments are finished.
Pretty short, but let's start design!
We can see rule is not valid for few processes, so let's add some Entities to fulfill this rule:
Now we can add estimation part. First: for every entity we can add complexity (we know that one entities can be more complicated than another), complexity of processes will result from used entities complexity:
So we know now that more complicated process will be sending order to an ERP system. If we added proper weights to operations (CRUD) and measure single activity we could estimate full effort needed to implement specified system.
Above CRUD translates into the following DFD: