UML is created for tech people for the task of OO designs, not for the purpose of business modelings. Visio is another popular tool to create diverse diagrams. I think that BPMN is created for business modeling only for business people and business analyst. From my readings BPMN is the most suitable for business modeling.
I think that there are tools to complie BPMN into BPEL but not compile UML into BPEL. Although BPMN is abstract out but I don't see why BPEL can not catch up with BPMN. XMI is information content standard not created for modeling or executing business processes and hence can not be substitute for BPEL. Jerry --- Hitoshi Ozawa <[EMAIL PROTECTED]> wrote: > +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 > >> > > >> > >> > >> > >> > > > > > > > > ____________________________________________________________________________________ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html
