How to design your business using Wolf...
The first step to approaching Wolf’s solution platform is Definition, the definition to your business design. The WSF Designer user should go through a simple exercise to achieve the correct definition before he gets started with designing his or her application into the WSF platform. After you have understood the basic principle of how to define your business, please visit the following section: Wolf Designing and delivery architecture
To go about defining your business, we'd like to ask a simple question.
Can you define all the participating Entities of your business?
Let’s put this into context of a business requirement.
Business Requirement
A company wishes to have all their employees’ information online. That’s it.
Design Process
Questions
- What Information?
- Employee Details
- Name
- Address
- Social Security / PAN numbers
- Blood Group
- Employment Information
- Department
- Designation
- Date of Joining
This information is good enough for our first Entity – Employee. But wait, is that our first entity? Is there a dependency on any other entity here? If we analyze each detail of the employee we can derive that some information should be a part of an external list.
Dependent Items
- Blood Group
- Department
- Designation
These are going to be selectable from a list of possible values. In the Wolf Platform a list is also treated as an Entity. Now we see that we have a list of our first set of entities with no further dependencies. We can safely conclude no further dependencies exist for the purpose of this exercise and start creating an Entity mapping table which will help us through the rest of our design process.
| Blood Group | Department | Designation | Employee | ... | |
| Blood Group | |||||
| Department | |||||
| Designation | |||||
| Employee | |||||
| Entity Mapping Table | |||||
If you notice we have mapped all the Entities so far on a table. The very same items listed in the first column and first row as well. This is pretty much the point where you enter the Wolf Designer and start adding your new entities but we’ll perform one more little task.
A task of relating...
- Blood Group
- Blood Group
- Department
- Department
- Department Office Address
- Department Head
- Designation
- Designation
The immediate observation is that Blood Group and Designation have single fields. No more extension of information there. This does not require a relation. The information is more of a static nature and does not extend the Employee entity by more than a single Detail.
On the other hand if we see Department Entity has three detail elements which extend through one mapping. A definite relation! Let’s now look at the mapping table once again. Only this time we include the relation.
By relating we mean to say that we wish to extend the information in an Entity with the information in another entity. In our example we could do this possibly between Employee and Designation. We could say that a Employee information is extended by its Designation information. But why can’t we call Blood Group and Department as extensions? It’s quite simple. Let us start by listing the details of each Entity.
| Blood Group | Department | Designation | Employee | ... | |
| Blood Group | |||||
| Department | |||||
| Designation | |||||
| Employee |  |
||||
| Entity mapping table with upward relations | |||||
A relational mapping shows us that an Employee would hold a relation to Designation as the Designation extends the information in an Employee by more than one field. With this exercise in mind, we are now ready to enter the “Wolf Designer Environment” as a designer user to building our first Employee entity with its prior dependencies of’ course.
