Note: Material Copyright Ali Arsanjani
Manners are rules governing behavior of a reuse element (like a class or a subsystem) within a given context (usually, a business context).
Manners cover a wide spectrum, from business analysis expression of business rules assigned to a reuse element to a grammar-oriented object design specification based on a domain-specific language for a business.
Here are some considerations regarding manners:
1. Business rules should become first-class constructs of the object and component paradigm.
2. Therefore, a class has not only identity, state and behavior, but also manners.
3. Manners are rules governing the behavior of a reuse element (class, ..., subsystem (--> component),...) within a given context, plus the meta-data needed to express the context, the rules and the conditions. Examples: XML, EJB Deployment descriptors, the Configurable Profile pattern (Part of the CBDI Pattern language) ["define a profile for each user type, so you can change the rules governing how the user type interacts with the system, their workflow, the rules that they have to abide by when they are offering products and services in a given office in a given geographic region (context) for a corporate (customer type) client within these time frames (duration constraint) e.g., until christmas.
4. Object discovery vs. component discovery -> fine-grained objects vs. medium to large-grained components
Instead of starting at a fine level of granularity, start with a higher level of reuse. Start your analysis at the subsystem level (a larger grained reuse element). Idenitfy the manners for the business domain. What are the rules governing behavior in this business domain? What are the contexts in which business events occur? What rules /workflow should be triggered?
5. Write a domain-specific language to describe a business domain. This consists of a set of production rules. They can be externalized and repreesented as XML. This enables a subsystem's DSL to govern the laws of its business objects and how they interact and collaborate to fulfill a business purpose.
6. The Enterprise Component pattern is used to implement a subsystem whose manners were described using the DSL. The DSL essentially captures the workflow within the subsystem[* see point 6.3 below] . This worklfow is managed by a Mediator within an Facade. The Mediator coordinates activities and workflow among a set of loosely coupled medium-grained components or plain business objects. The Mediator uses a Rule Object to externalize its workflow. Its colleagues (the components or business objects; that's their name in the Mediator design pattern) may each have a Rule Object that governs their rules. IN this way, you can change a component's behavior at two levels in a non-intrusive way: change the workflow by changing the Mediator's Rule. Change the business component's Rules by adding new Rule Objects (Conditions or Actions). Thus, the Enterprise Component, which realizes a subsystem will have realized its manners through the Mediator's workflow Rule Object. This can be represented as a grammar. This grammar (e.g, an XML DTD or Schema) can be parsed using standard XML parsing tools to decouple the workflow of the Mediator from its Colleagues (the business components or objects).
- Thus, we have built an adaptive system with three key attributes: dynamic configuration, dynamic collaboration and self-description.
6.1- The ability to adaptively change the workflow without stopping the application is dynamic configuration.
6.2- The related ability of altering a set of collaborations between objects or components ""on-the-fly" is called dynamic collaboration.
6.3-Footnote: the subsystem grammar or manners, describes the rules governing the behavior of the subsystem under events and invocations made to its facade. It also contains meta-data (the grammar) which can be queried (reflection) from another component who asks for our component to describe itself. This attribute is called self-description.
7. Thus, manners is a semantic notion of manners = rules + context + meta-data
8. Manners can be represented in a spectrum of realizations or implementation mechanisms:
8.1. If-then-else
8.2. Polymorphic Strategy-like implementation
8.3. Rule Type = Rule Object + Type Object
8.4. State Machine
8.5. Grammar (this ties it in with the notion of a domain-specific language).
* Note: Pay as you go: if you don't need the power, stick to a simpler implementation mechanism