+1. I use UML to document users' requests. UML is used as a common language for "technical" people to discuss and document ideas. The final result is usually converted it to a format that users will be able to understand when I need to explain it to them.
I'm not too sure about if there should be a standard modeling language for business people. H.Ozawa Dan Creswell wrote: > Steve Jones wrote: > >> 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. >> >> > > Indeed - as always the real issue is communication between techy and > non-techy and a techy solution based on the use of UML in my experience > is a complete disaster in waiting. > > Thus far it seems the best solution is still to get a customer in an > "interview" situation, ask them questions, scribble on whiteboards, get > it into use cases and then do another "interview" where you don't point > at the use-cases, rather you talk and use the whiteboard again using > customer terms and make sure you understood what the customer told you > last time. > > i.e. Keep it as non-tech as possible. > > One of the biggest revelations most techies have after talking to > "customers" is "they're stupid!". > > Actually, no they ain't stupid but they don't think the same way. > Techies like sequential, reasoned, binary organized thinking, > non-techies don't, they think in terms of anecdotes, rules of thumb etc. > > Almost all UML-related stuff is sequential and structured and customers, > consequently won't grok it. > > Two cents, > > Dan. > > > >> On 16/01/07, *Hitoshi Ozawa* <[EMAIL PROTECTED] >> <mailto:[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 >> > >> >> >> >> > > >
