The Rule Definition subphase |
|
|
|
In the USoft Approach, Rule Definition is a subphase of the DEFINE phase. The term "definition" in the subphase name emphasises an important advantages of the USoft platform, namely, the ability to implement rule-based behavior simply by declaring the rule in SQL or otherwise, without coding in a programming language. However, the more involves rule implementations involve relatively complex SQL statements that may be experienced as coding in their own right.
In the Rule Definition subphase, you specify and implement rules. Specifying rules Rules are specified when you work on tasks of the SPECIFY task type. By default in USoft, rules are specified by atomic, natural-language statements that express business rules in terms of SBVR. It is typical of USoft that desired system behavior or human behavior is expressed as business rules rather than software requirements. The advantage is that the specification is less dependent on project definition. It characterises not just a project goal but the target business conduct itself. Sometimes the difference between rules and requirements is very slight. The statement "System X may not be closed down for maintenance longer than 3 hours a month." is a business rule and a non-functional software requirement at the same time. Rules are defined in USoft Teamwork. Alternatively, USoft's URequire tool offers more innovatory options for Rule Definition. Alternatively, you can choose to define rules or requirements outside USoft, using a different format or tool, or using different methods and techniques. Some organisations simply use a list of tasks to be completed by a development team - this same list is used as a requirements list and a daily task list. However, such an approach cannot give you longer-term traceability and maintainability. You can specify rules in USoft Teamwork or in URequire without implementing them in USoft Definer. Implementing rules Rules are implemented when you work on tasks of the IMPLEMENT task type. By default in USoft, rules are typically implemented in one of two ways: •by setting attributes of domains, tables, columns and relationships in USoft Definer (so-called implicit rules - rules implicit in characteristics of the implemented structure) or, if the required attribute is not offered in the USoft meta-model, •by declaring the rule in a SQL statement that defines the required rule-based behavior (so-called explicit rules). In addition to these typical ways of implementing rules, a range of other options is available. Sometimes rules are implemented in batch job definitions, logical view definitions, UI elements or service-oriented interfaces. It is also possible to code rules-based behavior in a programming language and use that code inside the USoft Rules Engine by declaring it as an RDMI component in USoft Definer. Rule implementations are among the most distinctive features of the USoft platform. As the subdivision of the DEFINE phase clearly shows, USoft views "business logic" primarily as rules-based logic. This applies to applications that focus on rules-governed data access, but equally to other types of business software, such as service-oriented functionality, process flow implementations, workflow engines, decision engines, event processing and predictive rules. You can implement structures in USoft Definer or other USoft tools without first specifying them in USoft Teamwork or URequire. In fact, specifying them is completely optional. NOTE: The sequence of subphases Structure Definition - Rule Definition - Interface Definition suggests an ordering in time but this is relative. It is true that when you start working on a completely new area, you usually specify structure first, then rules, and then interfaces. But in all other cases, you are likely to make alterations to all three as you go along. Most rules clearly depend on structure. Interfaces are also fairly clearly related to underlying structure, but less so on rules.
See Also |
|
