The question isn't so much what can't be represented in UML (pretty much everything can) but whether it can be represented in UML in a way that the business understands. While I've had success of getting business users to understand use cases and simple activity diagrams they are just to "techy" to be used for outlining complex workflows or business process interactions.
So the problem isn't just whether UML can represent it, its also whether that representation is understandable. On 16/01/07, Hitoshi Ozawa <[EMAIL PROTECTED]> wrote:
Hi Ashley, Yes, state chart derives mainly from real-time/embedded system design but activity diagram, which is a special case of state chart diagram, has been used to design business domain. That said, I'm always open to new ideas. I'm sorry but I'm still having understanding the differences. Can you provide me with an example of concrete business situation which can not be represented by an UML diagram? Also, would greatly appreciate if you can provide me with more information. Thanks, H.Ozawa Ashley at Metamaxim wrote: > Dear Hitoshi > > >> The paper cited does not use UML state chart diagram, but I think the >> concept is the same. >> > > Actually, the concept is very different. The key differences are: > > 1. UML state charts do not support the idea of event refusal. > 2. UML state charts cannot be composed in the way we describe (using CSP parallel composition). > 3. UML state charts do not support derived (calculated) states. > 4. UML state charts do not support different behavioural types (Essential, Allowed, Desired). > > The detailed semantics of UML state charts derives mainly from the work of Harel and Shlaer/Mellor, and has its origins in real-time/embedded systems design. They are not suitable, in my view, for work in the business process domain. > > Rgds > Ashley >
