top of page

- Application Requirements.

 

Conventional wisdom says that there are three types of Rules that need to be identified when specifying a computer system:

  • User Rules, that specifically target the rules, which say how the users will interact with the Computer in order to achieve their User goals.

  • Business Rules that specify what the business, apart from the users, wants from the system in order to achieve Business goals, and

  • System Rules. These rules are not a key topic of this paper, but are still important.

​

For example, a salesperson in a cake shop has the user goal of selling cakes. However, the business goal is to make a profit.

Most of the day, these two goals don’t refer to one another, because the price of the cake remains constant. 

  • If the salesperson just “sells cakes” for the set price, then they are achieving their goal.

  • The Business staff have to make sure that the cost of the cakes has been taken into account. So, the business has goals like ‘Set the sales price!’ 

  • However, there may be another business rule that says that, at the end of the day it is better to sell all the cakes at reduced prices rather than have any left. So that the business rule may allow the sales price to be reduced by the salesperson, after 4:30m at their discretion.

​

 

It always pays to make the distinction between the Business and the Users. One good reason for making this distinction is that UML can then be used to cater for the two sets of rules differently but very cleanly:

  • The User Rules can be described using Use Cases that show the Interaction between the user and the system. They can also be described independently from the Business Objects. Use Case diagrams show what use cases exist and how they are grouped and related.

  • The Business Rules can be described using Domain Diagrams (specialised Class Diagrams) that show Business Objects. These can be identified and described independently from the Use Cases that call them.

  • The System Rules can then be built into the Business Classes or alternatively, built into specific ‘System Business Classes’.

 

This three way split, sometimes called the MVC (Model – View -  Controller) architecture:

  • Model:  ‘Domain Diagrams’ that define the Business Objects and their associated Business Rules.

  • View:  'Use Case Diagrams’ that define the steps required by the users, when performing individual user tasks on the system.

  • Controller: ‘Sequence Diagrams’ used to tie the above two together.  An ‘application controller’ describes individual sequences from one use case and controls how it relates to the requisite business objects. Some organisations prefer to describe the controller scenarios with text or flow charts written in a style of formatting that suits the project. There is a wide variety of styles.

  •                                                                                                        my advice "KISS - KEEP IT SIMPLY SIMPLE"

 

 

 

. CONTROLLER - Sequence/Object Diagrams/Text . .
bottom of page