Delegate Code Generation
The Moxie plugin for No Magic includes a utility to auto-generate Java interfaces and classes from the blocks in your model. This significantly decreases development time and ensures accuracy by generating the correct property names and method signatures to match your blocks' properties and operations. You can find the code generation utility in the Moxie menu of your No Magic modeling tool.
Required inputs
-
Target SysML package or specific block to generate from the
Containment Tree
in your No Magic modeling tool - Output directory
- Default Java package name
Optional inputs
- Include @AutoDelegateImplementation
-
Include class implementations
- Class prefix
- Class suffix
- Generate abstract class?
- Generate delegate provider?
- Delegate module name
You can also specify an override for the Java package name for a specific block or package by using the CodeGenerationJavaPackage
stereotype provided in the Moxie-Base
SysML model library. The value you specify for
this stereotype's tag will override the package name the code generation utility will use when generating interfaces and classes and when
referencing them from any other generated code. The
Moxie-Base
and
Moxie-Core
libraries provided with
Moxie
have been annotated in this way. So, when you generate your code referencing them, it will use the correct
import statements. Note that if you generate interfaces or classes for models provided with
Moxie, they will use package names from com.agi.moxie.*
.
However, you should not include any of those generated files in your delegate modules. Otherwise, you will run into conflicts at runtime.
Interface generation
Since a majority of simple blocks will have implementations provided at runtime, consider generating interfaces for them if you need to reference the automatically implemented properties from other types. This is particularly useful for simple data containers. This also pairs well with the @AutoDelegateImplementation system.
These interfaces are intended to be generated and re-generated whenever the SysML models change. In this way, Moxie supports the traceability and maintainability between the Java and the SysML model. So, ideally, these files would be included into your Java project in a way where they can be re-generated and recompiled easily to highlight any changes in the SysML as compile errors in Java. However, the interfaces can also serve simply as sample code to help streamline the development process so you can pull in the properties and operations that you need to implement.
Class generation
In addition to interface generation, Moxie also provides class generation. These generated classes allow you to get up and running with Moxie as quickly as possible. The created classes will contain implemented properties, annotations, and type hierarchies that are set up in an intelligent way across all classes. These classes are meant to be edited and not regenerated.
You can choose to produce the classes by ticking the Generate Class Implementations for Generated Interfaces
checkbox in the Java Code Generation window. Only the item that is selected in the Containment Tree and the items it
contains will be generated. If no items are selected in the tree, then all non-auxiliary items in the containment tree will be generated except
for the Moxie model libraries.
All classes will be produced in a .impl
subpackage with interfaces generated in the parent package.
Prior to generating the classes and interfaces, this part of the code generation tool allows you to:
- Specify a prefix for all generated class names.
-
Specify a suffix for all generated class names.
Delegate
is the default suffix. - Select whether or not to generate abstract classes.
-
Select whether or not to generate a
DelegateProvider
implementation with the generated classes. -
Specify the name of the delegate provider to create, if desired. The default name is
CustomModuleDelegateProvider
.
Classes marked as abstract in the SysML will not be generated even if selected in the Containment Tree.
Packages with the MoxieExcludeFromClassGeneration
stereotype will have all elements within excluded from class
generation.