Requirements Modelling and Specification for Service Oriented Architecture

7.6. Finding Business Rules

With business and software modelling, a large number of lessons can be learnt from AI systems built using semantic nets and from semantic data modelling. Specifications that exhibit encapsulation of attributes and operations are all very well but do not necessarily contain the meaning intended by the analyst or the user. To reuse the specification of a component we should be able to read from it what it knows (attributes), what it does (operations), why it does it and how it is related to other component or service interfaces. It is my position that this semantic content is contained not only in the static structures of association, classification, composition and messaging but by the assertions, invariants and rulesets which describe a component's behaviour.

The fact is that all semantics limit reuse, although they make it safer. For example, inheritance does so; and so does anything that makes the meaning of an object more specific. In system specification, both aspects are equally important and the trade-off must be well understood and managed with care, depending on the goals of the analysts and their clients.

One must also be aware of the need to decide whether rules belong to individual operations or to the service as a whole. There is no principled reason why operations cannot be expressed in a rule-based language. However, the distinction to be made here is not between the form of expression but the content of the rules. Rules that relate several ...