Steve, I know that we were getting a little off topic here but curiosity just got hold of me.
You are definitely right that UML diagrams are not for business people. But then, we don't expect business people to do requirement analysis. : ) The point is, on a large project, I don't expect business people to do requirements analysis. I don't think SOA is about enabling business people to "develop" a large scale system just on their own. I think it's more of developing a system to enable business people to get a better control of interactions between business services. I don't see the reason to restrict it to rule-based or to procedural. Regards, H.Ozawa 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.
