Editing Types
Start arKItect and open an empty database without using any template. Name the project "Processes management". If the Rules and Filters panel is not visible, you can find it in Show / Hide Panel of the Tools Category.
Let us begin by creating our first object type.
Right-click on the project root (named "Processes management") in the Rules section and choose Add Rule from the context menu.
The term "rule" stands for a relationship between a type and another. Here we want to define a new type under Root. Root has the name of the database. It is the type at the toplevel of the hierarchy.
So we select Root (Processes management) and ask for adding a relationship with Root.
A type properties window raises. Name the new type "Orga" to metamodel Organization (team/people) under the root as stated on the example diagram.
The name is defined in the Select type field.
You can also define the graphical properties of the new type that will apply to all objects of that type. The shape of an object is by default rectangle. You can set the icon of the object as a predefined icon in "Memory".
Select the following icon:
Now go to the Border Line tab and set the border line color as black. Define the width of the line as 2 point.
You can now click on Add, and the type definition window closes. You can see that the type "Process" has appeared (represented by the previously defined icon) in the Rules tree under the "Processes management" root object.
Let us now define the type "Orga" as recursive, i.e. each "Orga" can contain one or more child "Orga" (to model an hierarchy). To add a reference to the "Orga" type under itself, select it in Rules and drag and drop it onto itself. This action adds an identical "Orga" icon beneath the existing one.
Let's add now the "Process" object type. But if you remember the example diagram, "Process" are under "Set of processes". So we have to add first object type "Sef of processes". We have to act similarly to the case of "Orga" (with a green border line set to 3 Point and icon: 
) to obtain the result below:
We can now add "Process" type as child of the "Set of processes" type. Go to the parent "Set of processes" type, right-click on it and choose Add Rule from the context menu. The type definition window opens. Define the name of the type as "Process" and click on Add.
You can now see the "Process" type appears in Rules. However, as we forgot to define the icon and other graphical properties of the type, let us go back to its properties definition window.
Right-click on the "Process" type and choose Properties from the context menu.
Let us define the icon of the type 
as well as its shape (rounded rectangle). Click on Fill in the menu tree, and choose the foreground color light gray. Click on Save then Close.
Notice:
Suppose we had created "Process" type at a wrong hierarchical level (for instance, directly under the root instead of child of "Set of processes"). To add the type the correct location in the type hierarchy, right-click on the "Set of process" type and choose Add Rule from the context menu. Now, select "Process" from the Select type list and click Add.
The "Process" type would now appear beneath the "Set of processes" type.To delete the "Process" type as child of the root, click on the rule's icon and choose Delete Rule from the context menu. You should be careful when deleting rules: the deletion also removes all objects created using this rule!
It is also possible to drag&drop a type from a location in the metamodel to an other in order to add rules.
At the moment, we have only created hierarchical relations: this means that objects of the parent type are presented as containers containing objects of the child type. In a flow relation, the parent object can produce and consume flows of the child type.
Let us now create the type "Document" as a flow under "Process". Right-click on the "Process" type and choose Add Rule. Name the type "Document" and, in order to to define the relation as a flow, check the It is a link check-box and define the flow as of type Input/Output. Let us define the icon of the flow 
as well as its text color (magenta) in the Font tab. Define also the flow color (magenta) and the flow width (3 Point) in the Link Line tab. Then click Add.
Add the flow "Item" performing same actions.
In Rules window, you can see a small white arrow icon beneath the icon presenting the flow types (either "Item" or "Document"). This icon indicates the relation has been defined as a flow.
If you now go to the Properties window of the "Document" type, you can see that the It is a link check-box has been grayed out. You cannot thus undo the relation's definition as a flow once it has been made. The only way to change it would be first to remove the rule.
Processes can now produce and consume "Item" or "Document" flows; however, "Document" type has not been defined as a child of "Orga" for instance. So, "Orga" type cannot neither receive nor produce this flow. If we wanted such a beahviour, we would have to add "Document" type as a child of "Orga", e.g. by a drag and drop of "Document" type under "Orga". You could see in the rules treeview that the icon denoting a flow relation is missing in this new instance of the "Document" type. You need to go to the type properties (right-click and Properties) and to check the It is a link check-box to define the new rule as a flow. But we don't need this behaviour for the current meta-model. So a type can be a flow at one place of the metamodel and an object at another place.
The criteria "it is a flow" is thus related to a given rule (parent-child relationship) and not to a child type. This is because it is sometimes convenient to define types that have both flow and non-flow object relations. For instance, one might wish to model differently a data flow produced by a function, and its allocation on a physical interface.
Finally, as we want to allocate organization to processes, we have to drag and drop "Orga" type on "Process" type. You now have arrived at the the final Rules definition illustrated on the screenshot below:
As we have now finished creating our type hierarchy, you can define the type attributes.
Editing Attributes
Previously, we created a hierarchy of object types via Rules. However, we have yet no type attribute allowing to characterize objects of a given type, e.g. for providing a description, an author, a physical unit, an identifyer, a date of creation or revision, a program operating on the object... attributes can thus contain data in the form of text, numbers, dates, scripts, files, etc.
Let us add a "description" attribute to "Orga" type. In the Rules tree, right-click on the Attributes node beneath one of the rules of the "Orga" type and choose Add Attribute from the context menu.
Name the attribute as "desc" in the Name field and define the type as String(255). Then click on the Add button.
The "desc" attribute now appears in Rules, beneath the Attributes node of "Orga". You can see that the attribute is present in all the rules of the "Orga" type. All instances of a given type are therefore identical in terms of their type attributes as well as in terms of their child types.
Now we can see that "desc" attribute can be also useful to describe "Document", "Item" and also "Process" Rules. As we have already add it to a Rule, we just have to drag-n-drop it in all other listed Rules. It will be automatically "copied" in the "Attributes" node of each of those Rules as illustrated:
Let us also create another attribute: right-click on the Attributes node of the "Set of processes" type and choose Add Attribute from the context menu. Name the attribute "Processes type" and define it as an Enum (enumerator) attribute. Enumerator attributes have a predefined list of values. Click on Add to create the attribute.
We now have to define the values of the created enumerator attribute. Right-click on the "Processes type" node and choose Add Attribute from the context menu. This action opens a window that permits us to define a value for the enumerator attribute. Name the enumerator value "Purchase" and then click Add. Create three more attribute values in the same manner, namely "Technical", "Project management" and "Non defined".
We have not set any default value for our enumerator attribute: to do this, right-click on the "Processes type" attribute and choose Properties from the context menu. Check the Default value check-box and choose the value "Non defined" from the list. Now you can Save the changes.
You can manipulate type attributes in the same manner as object types in Rules: it is possible to copy them to new locations in Rules by dragging and dropping and they can be deleted by choosing Delete Attribute from the right-click menu.
We have now created our meta-model composed of object types and type attributes: this meta-model defines our modeling language.
However, we cannot yet create any object instance using the defined types: this is because we have not yet any editing view or diagram to ad objects. Let us now start working with Views.
Editing Views
In order to design Views, click on the "Filters" section title visible at the bottom of the Rules and Filters panel.
At the moment, only the "Processes management" root object is visible in Filters. In other words no view has been defined yet.
To create your first view, right-click on the project root and choose Add Filter from the context menu. Name the filter "Processes":
Leaving the check-box Copy rules checked creates a filter that includes all the rules defined in Rules. After clicking on OK, the "Processes" filter appears in the Filters list. You can verify that all the rules related to types as well as to their attributes are checked in this filter. It means they will be visible in our view. As we want in that filter just to deal with processes, we need to change the selection of checkboxes as illustrated below:
At this stage, we need some clarification about terms. We call filters or projections the views that can be produced automatically in arKItect.
The intuitive algorithm behind filters is "show me all objects that are selected". practically, filters are like projection of the overall database on certain types forgetting all the others.
This explains why filters are generative. If you have an existing database and define a new filter, all objects meeting the filter definition will be displayed automatically.
This mechanism proves to be very powerful. With practice, you will see that it enables building non trivial views on the one hand, and that on the other hand, it answers most of the views you would expected on your data.
Let us also create a "Organization" filter: as before, right-click on the project root folder and choose Add Filter. Name the filter "Organization", uncheck the Copy rules check-box and click OK. Now, go to the "Organization" filter in Filters and check all the check-boxes linked to "Orga" Rule under the root (not the one under "Process"). Do not forget to check the check-box of the "desc" attribute of the "Orga" type: this permits to render the attribute visible in the projection (result of a filter applied to a model). To help you do this, you can right-click on the "Orga" Rule child of root and opt for "Check Rule and All Subrules" as illustrated:
We have now created two filters: one that permits to visualize Organization and another that allows us to manage Processes. Now, let us create an Allocation filter providing a projection of Processes with their allocated Organization. Right-click on the root node in the Filters section and choose Add Filter from the context menu. Name the filter as "Allocate Orga to Processes" and click OK. Set the related checkboxes as below (you can right-click on "Set of processes" node -> "Check Rule and All Subrules"):
Notice:
In arKItect Designer, you can also define a new filter as a subfilter: that is, a lower-level filter dependending on its parent filter.
Note that you will not be offered the option Copy rules in that case: this is because the rules of the subfilter (i.e. the checked types) are by default identical to that of the parent filter. A subfilter can thus only contain elements present in the parent filter; it provides additional limitations on the parent filter rules.
Now we have three main filters but they are not ordered as we wish (in the Projections list view), because arKItect order by name. So, to "force" our order, we just have to rename the filters by adding for instance "1. ", "2. " and "3. " at the beginning of their current names:
We also wish to define a filter by default so that when the project is opened, it automatically opens on the chosen projection. To do this, right-click on the "Processes" filter in Filters and choose Set Default from the context menu. This default filter is now highlighted in bold font in Filters.
Now that we have created our filters, we can test them. Display the "Processes" projection via the Navigation Panel of the Home Category. You should now see the "Set of processes" type appear in the Palette. (To display the Palette, use Palette button in the Home Category or use Ctrl+Shift+D shortcut)
Notice:
When you look at the Palette, you can see that the "Process" type is not present: it is thus not possible to "Process" in the Internal Block Diagram although they are visible in the projection! The creation of new "Process" instances is impossible because there is one hidden hierarchical level, the "Set of processes" level. As "Process" objects are defined as children of "Set of processes", they cannot be added unless the "Set of processes" inside of which they are to be created is known.
Add now a one "Set of processes" objects, in the Internal Block Diagram; you now see the "Process" types appear in the Palette.
Now, add two "Process" objects inside the Set of processes and both types of flows between these processes, Expand all objects to see inside:
For more information about Filters, refer to the related documentation.