Technical Documents
Authority Modeling Wizards - From Implementation to CRM
Change Management
Importing an existing object-oriented software system (e.g. Java, .NET, and XSD) into Authority so that its objects and functionality is completely available to Authority statements is now even more straight-forward with the addition of the Authority Modeling Wizards. The Modeling Wizard in Authority makes this process easier by keeping track of what needs to be modeled, while maintaining the cross-references for the corresponding data types. For each object in the object hierarchy of the legacy system that needs to be modeled, a corresponding entity in Authority is automatically created. All fields and methods are modeled as relations in Authority. In some cases, the fields and parameters are associated with concepts as well, all of which are included in the new Modeling Wizards.
The goals of the wizard are:
- Input all of the external object model in an automated way
- Result in a model accessible to Authority statements that is
- complete (models everything available in the object model)
- consistent (has no ambiguities or internal contradictions)
In addition to the above, there are a number of principles that the wizard adheres:
Some of the design criteria used for the wizard were:
- The wizard has an intuitive and consistent interface
- The wizard minimizes the amount of time taken to model an existing system
- The wizard is simple and straightforward to use
- The wizard has reasonable defaults for any questions and allow the user to change them as needed
- The wizard does not require input for information that is otherwise available
- The wizard avoids unnecessary inputs or questions
The preceding goals translate into the following features:
- The wizard constructs the relevant concepts (and templates) that are needed to model a Java (or .NET) class
- The wizard constructs the relevant concepts, relations, and templates that are needed to model the procedure for a Java (or .NET) method
- The wizard constructs the relevant concepts, relation, templates, and attributes that are needed to model a Java (or .NET) field
- The wizard constructs the relevant concepts, relation, templates, and attributes that are needed to model the field for a .NET property
- The wizard constructs the relevant concepts and relations to model the complex type for a template that corresponds to a complex type
- The wizard supports modeling an entire implementation as well as a specific piece of the implementation
- The wizard provides the context in which it is asking questions so that the user can understand what is happening
- The wizard supports creating templates for classes without modeling, attributes for get methods with no parameters, and attributes for fields
An Authority implementation wizard maps all accessible items to equivalent items in Authority. These items should include classes, public attributes of a class, public methods of a class (including the constructor), public class-level (i.e. static) attributes, and public class-level methods. For each type of item to be mapped, there will be a number of aspects of the mapping that the user is able to select or modify.
Mapping classes
Classes are the fundamental definitions within Java, so everything needing to be modeled in a wizard should stem from them. Java classes correspond to entities in Authority, since they are concepts defined by their relations to other items.
Entities can be implemented in an Eclipse template, which in turn can be used to identify a particular class or interface. Java and .NET support single inheritance in the class taxonomy, so an Eclipse template hierarchy that is analogous to the class taxonomy in Java and .NET is maintained.
When modeling classes, the user is able to choose whether to model the class or not, and if so, what noun phrase to refer to instances of the class. A reasonable default is generated from the class name.
Mapping fields
Fields of classes is able to be modeled in Authority under three conditions:
- that they are part of a class that is to be modeled
- if they are defined as public
- if the type of the field is to be modeled in Authority
If the field type is a primitive type in Java, then it should correspond to an equivalent 'value' in Authority. If the field's type is a Java class that will be modeled, then it should correspond to that class's corresponding entity. If a field can be modeled, then the user is able to choose whether to model the field.
Fields are modeled as relations in Authority. Since public static fields in Java are used to define constants, such fields are modeled as instances of the appropriate type in Authority. Since static fields do not use an instance of the class, the concept corresponding to the class would not be included in the relation being used to model the field.
When building a relation for a field, the wizard should suggest a noun phrase that will be used by the relation wizard to build an initial phrasing.
Mapping methods
A method corresponds to a relation in Authority. Only public methods would be available for modeling. If a method is to be modeled, then the corresponding class must also be modeled. Users are able to select which methods to model. Modeling a method requires modeling the class and modeling the type for each parameter and return value.
A method would be modeled as a relation that includes a role for each parameter, a role for the instance unless the method is static or is a constructor, and a result role unless the method has no result. Constructors are modeled as returning an instance of the class.
As for attributes, when building a relation for a get method, the wizard should suggest a noun phrase that will be used by the relation wizard to build an initial phrasing.
Modeling collections
The modeling of collections needs to be dealt with specially. A method (or field) in .NET and Java that returns (or is) a collection is modeled like a normal method (or field) with the exception that the data type in the collection is used to define a role in the corresponding relation rather than the collection type itself. When invoking the method (or retrieving the field), Authority will generate a code that will iterate through the collection and build relationships for each item in the collection.
In order to model the method (or field) correctly, the wizard will need to determine the data type for items in the collection. Since Java 1.5 and .NET 2.0 support generics which allow for obtaining the data type in the collection, the wizards need not ask. However, when supporting non-generic collections in Java and .NET, the wizard will have to ask about the data type in the collection.
High Level Overview
The modeling wizard dialog is in control of the modeling process by making a separate call to the rule engine per task. The modeling wizard dialog would initiate the next task when the user pressed the next button. If the user pressed the cancel button, then the modeling wizard would exit the (sub)task. If desired, the modeling wizard could support a skip button that skips the current task.
- The wizard uses Microsoft's wizard metaphor
- The wizard shows context as a scrollable list of tasks in the top section of a wizard pane, e.g.
- modeling com.haley.examples.insurancefrauddetection.Claim
- modeling java.util.Collection getPartyInvolvements()
- The wizard supports Back to return to the previous state
- The wizard supports Next to control the modeling process
- The wizard support Cancel to abort the current modeling (sub)task
- The wizard leverages the existing concept acquisition wizard as a sub-task. The concept acquisition wizard will be responsible for acquiring the phrasings for the concept and will leverage the dictionary service, if available. In any case, the concept acquisition wizard will be used to define a concept outside of any modeling wizard, so the user will only have to become familiar with one process
- The wizard leverages the relation dialog
- The wizard will ask if a numeric primitive data type corresponds to an amount, a percentage, or a simple quantity
- The wizard will ask if a java.lang.Date, a System.DateTime, or a xsd:datetime, corresponds to a specific date or a specific time.
- The wizard will ask if ancestral concepts is modeled whenever the user indicates that a class is modeled
- The wizard will ask which methods are modeled whenever the user indicates that a class is modeled
- The wizard will assume that any class used in a method that is modeled is modeled
The rules will not create a concept, relation, or phrasing, but rather will initiate wizards/dialogs to do so, thereby allowing the user to use the authoring environment they are familiar with, and making it easier for Haley to develop, maintain, and test the wizard.
When initiating concept acquisition, the rules will suggest a noun phrase based on the name of the class.
The wizard will not attempt to define a phrasing, but as phrasing acquisition matures to a wizard that acquires a phrasing from a clause, the wizard could suggest a clause for a method based on the name of the method.
Contact us for more information at: info@haley.com or call 1.877.478.7853
Download the Authority Modeling Wizards Datasheet
