In the last post, we discussed about identifying policy model needs, documenting sources of information, identifying perspective and tense. This article is more focused on entities and relationships.
Entities allow much more complex logic to be authored in the rule-base. When designing your entity structure, it is wise to think about future phases of the project as well, and whether future extensions to the rule-base will require entity reasoning. This way you save yourself some effort and can revise later on. An entity should be used when you have a set of ‘things’ and you need to collect data about each member of the set, and you need to do logic over the set.
The name of entity should start with definite article “the” and refer to what the entity is. Name of entity relationship should also start with the definite article “the” and it should be a meaningful name that describes the relationship. This requires taking into consideration what type of relationship is being described, e.g. one-to-many, many-to-one, many-to-many, inferred relationship. It is also important to choose appropriate names for the entity relationships as these names appear throughout the project.
You can describe the entities and relationships in a way that will make the most sense to the readers of your design document. This can include a description of each entity and relationship, a table of entities and relationships or may be a diagram or a high level data model. You can also use a combination of these techniques to describe your entities and relationships.
IDENTIFYING DESIGN CONSTRAINTS
Design constraints are anything that influences the options you have available while preparing a policy model. This can include:
- User:Level of understanding, subject matter knowledge and familiarity the end-user has with similar systems can affect the outcome, complexity, and procedural flow of the policy model.
- Timeframe:Once you have finished your design you may find that it is simply not possible to complete everything within the required timeframe. If your design cannot be achieved within the desired timeframe, you may need to revisit your design to see where you can improve efficiency or may be remove non-essential components.
- Existing Data Model:If your system is integrating with an existing data model, you may find that the policy model needs to include more attributes than you originally intended.
- Skill-Sets:The skills and experience your team brings may allow you different levels of creativity in your policy model design.
- Information: Information you have available to you at the start of the project is usually the information on which you base your design. When you know you are likely to receive additional information your design needs to be flexible enough to accommodate this.
Designing with constraints can result in some creative design outcomes, thus making your policy model more efficient and effective.
