I am some what surprised by the comment below:
"pretty much everything can"
From my experience and many colleagues and friends in the industry
we would not agree. UML is pretty good but it only provided local
behaviors rather than any sort of global model. If you want to
describe how a MarketMaker works you can do it. You can even describe
it's complement - the MarketTaker. But you cannot describe both in a
collaborative global fashion. Rather you are left to make the
connections between the roles yourself.
You may well be able to describe this stuff in UML but it is very
hard to do so and highly prone to errors. Just because you can
doesn't mean you should.
Having a clear description at a global level of the behavior of
different roles and participants would in such a way as to generate
the necessary local UML artifacts from that global description would
be a better way to build systems. I think the next major release of
the pi4soa open source CDL stuff will go some way to doing this. The
marriage of a global description with UML generation has already been
in use at ISDA (for FpML) and ISO (for WG4) for sometime.
I'd be interested in how others manage global models.
Cheers
Steve T
www.pi4tech.com
On 16 Jan 2007, at 09:59, 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
> >
>
>
>
