The Shaman Scripting Language is used to program the Brainet Platform. Shaman is different from traditional languages. It is fluid and its reserved key words change depending on the model. The model describes a project design with data, data relationships and data behavior. The name of Shaman describes an American Indian mystic who has the ability to shape shift into different animals. The analogy is that a specific model shape shifts into the Shaman Scripting Language.
Traditional languages have a constant set of reserved words with predefined meanings. These programming languages allow to write diverse and rich range of systems easier because the tools are fixed. Brainet’s approach is different. We do not want to write universally. This is because our main focus is to graphically program with drag and drop tools.
Success at graphical programming requires minimizing the scope of a language. For programming a traditional language, one can define an infinite variety of classes and properties. How would one describe graphically these infinite possibilities ? But with Shaman, there is a predetermined list of classes with their list of properties. This restriction gives us the ability to point and click on a web page’s limited ordered list.
Brainet’s Platform consists of a collection of Network Threads. A Network Tread is a program that allows sharing of data. In other words, it is a component of a distributive network. A Network Thread contains an engine which transforms models into a running program. The model is associated with the Network Thread through XML files. The individual models of the Network Threads combine as a single entity with a shared intelligence.
The modeling has three levels. The first is the hard infrastructure, which are libraries. These libraries can be moved from project to project without any coding changes. For example, the Mail Service which delivers messages between Network Threads. The envelop remains unchanged with “To” and “From” address as the parameters. The contents of the envelop is generic and can be used for any message.
The second level is the soft infrastructure. The soft infrastructure uses a number of builders. One example is the Noun Builder which defines the class specifications through a graph. The classes are at the nodes of the graph. The graph’s arcs are the class relationships. For example, the following graph is used in an insurance agency . The “Customer” owns a “Property”. The “Property” contracts a “Policy”. The “Customer”, Property” and “Policy” are classes. The arcs are “owns” and “contracts”. What this describes is Customer can own multiple Properties. And each of these Properties can contract multiple Policies.
In addition, each classes<class> in the Noun Builder defines a list of properties. This includes a label and a data type for each property. So when the graph is completed, there is significant amount of information available to define the Soft Infrastructure. A schema for a database can be automatically generated which supports a Network Thread’s database. A schema for the contents of messages so the packing and unpacking messages can be supported. Error processing can layered into the language because of foreknowledge of classes, their relationship<relationships>, and their properties.
The hard and soft infrastructure are integrated into the scripting language. For example, writing code to instantiate an object would be as follows: “var a1 = customer.new()”. This is simply described graphically. The first click selects “customer” from a pull down list of supported classes. The second click is for the “new” action. Automatically the rest of the code would be generated. The “var” is a key word for variable. The language has strong type casting but its support is hidden within the language. Errors are immediately flagged during the writing of a statement. The variable identifier of “a1” is automatically retrieved from a generator which guarantees uniqueness. And finally the equal sign is inserted for a completed statement. This is all done in two clicks. The purpose of the scripting language is build actions. Actions drive the behavior of a model. A list of actions are assigned to each class within the Noun Builder.
The Network Thread’s engine supports another level of automation within its infrastructure. For example, the infrastructure support a request/response cycle. When a request is received, it is a given that a response needs to be sent. So every action is prefabricated with the code of the request message at the top of the action and an empty response message at the bottom of the action. Except for the “To” and “From” properties whose values are known to the infrastructure.
The final level of automation is design patterns. There are certain patterns that constantly reoccur in this space. For example, the querying of data on the platform. The platform data is stored in tree graph. To retrieve the data is a two step process of scoping and filtering. Scoping identifies a sub-tree. For example, query for a specific customer. It’s sub-tree would consist of the customer, the customer’s properties, and the policies of the customer’s properties. This would take thirty one (31) lines of code to write. It would take time figure out how to write the code and to clean up the syntax. Then one would write test cases to prove the code. Or one could go to the Verb Builder, and with three clicks generate the code automatically. The second step is filtering which consists of restricting the search within a sub-tree. For example, a filter could restrict the search for a specific customer to only Policy classes whose policy is due to expire within a month. These filters are built graphically.
The Shaman Scripting Language focuses on the customization of code. The platform is built supporting mathematical models which describes the essence of a software design. Through drag and drop tools, a design can be actuated. The end result is a large productivity gain because the engineer is working at a higher level. He is conceptualizing systems instead of being immerse in the detail.