From STLab

Functionalities

Here you find use cases and associated scenarios describing main functionalities characterizing this version. Possibly enriched with Use case diagrams and related scenarios templates.

Some terminology

• Widget: a single interaction object in the Kali-ma dashboard
• Dashboard: the Kali-ma interface including a widget for each available plugins and Kali-ma default widgets e.g. CODO widget, and ontology element selection
• Profile: a set of widgets associated with a specific ontology project that are visualized in the dashboard
• All-widgets profile: a default profile including all widgets

• Kali-ma default widgets
  • CODO Widget (profile manager)
  • Dashboard Profile Manager Widget
  • Ontology Element Selection Widget

CODO Widget (CODO based selection of plugins)

• This widget lists all aspects of ontology design according to CODO light definitions: Project Management, Discussion and Evaluation, Workflow Management, Reengineering and Refactoring, Design Patterns
• Each aspect is associated with the list of plugins supporting it, meaning that if the user points to a certain aspect (can be mouse roll-over, selection, etc.) (s)he is faced with the list of plugins that address such design aspect.
• The user can select different plugins supporting different aspects
• The user can save a profile composed of selected plugins, either a new profile or replacing an existing one
• The user can open the selected plugins in the NTK.
• The user can configure the CODO widget in order to show either only active/available (means installed and enabled) plugins, or all existing plugins, including the active ones.
  • In case the second choice is selected, the widget plugin allows the user to select existing plugins in order to drive him/her to plugin download/installation wizard within the NTK, providing the URL of the update site for the plugins.

Dashboard Profile Manager Widget

Widget Dashboard

Structure/Architecture

• Put here most important classes and their relations with some comment describing the diagrams. Possibly enrich with Class diagrams.

Behaviour

• Put here behavioral aspects of the classes that are involved in the main/key functionalities, specially for complex ones. Possibly enrich with Activity/State and Interaction Diagrams.

Deployment Architecture

• Put here a description of the actual technologies and associated components you are using/developing and how they relate to each other in a running environment. If you find it useful enrich the description with Deployment diagrams.

Note:Please be sure to keep consistency between diagrams

End-user Documentation

Plug-in developers

Describe your plugin (C-ODO-wise)

Give Kali-ma an access point

Don't be afraid: there is no need to expose your plug-in implementation. Besides, Kali-ma wouldn't know what to do with it. However, you will need to at least implement a small interface and describe what types of resource your plugin needs and what it will provide itself.

Describe your plugin (Java-wise)

/**
 * Use this annotation on a generic method (e.g.
 * <code>IComputationalTask.execute()</code>) to formally assign types to its
 * parameters and return value.
 * 
 * @author Alessandro Adamou
 * 
 */
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Signature {
 
	/**
	 * An optional, user-defined identifier associated with the method. It needs
	 * not be the method's name, nor does it need to be unique (at this stage).<br>
	 */
	String name() default "";
 
	/**
	 * An array of types, one for each parameter expected by the specific
	 * implementation, if any. The type order will reflect the way parameters
	 * will be provided by Kali-ma. It is up to the implementor to check the
	 * correctness of parameter types and their order.
	 */
	Class<?>[] parameterTypes() default {};
 
	/**
	 * The type of the value returned by the method, if any.<br>
	 * <br>
	 * Default is <code>void</code>, therefore void procedures need not be
	 * annotated with this field. Alternatively, <code>void.class</code> can
	 * be used.
	 */
	Class<?> returnType() default void.class;
 
}

Here is an example of an implementation of the execute() method annotated with a Signature annotation.

In this example, the task associated to this method:

• has an arbitrary name "My Task";
• requires, in strict order, an array of strings and an integer as input parameters
• it declares that it will return an array of OWLEntity (as in OWL API) objects.

public class MyComputationalTask implements IComputationalTask {
 
	@Signature(
		name = "My Task", 
		parameterTypes = { String[].class, int.class, }, 
		returnType = OWLEntity[].class)
	public Object execute(Object... params)
			throws UnexpectedParameterTypeException {
 
		// Parse the first two arguments (the only ones needed in this case).
		Object arg0 = params[0];
		Object arg1 = params[1];
 
		// You should manually cast them to the types declared in the
		// Signature annotation. If their class does not match the expected 
		// type, consider throwing an UnexpectedParameterTypeException.
		// Kali-ma does handle exceptions of this kind.
 
		OWLEntity[] results;
 
		// ... (do what is needed to produce the outcome of this task
		// as an array of OWLEntities. Make internal plug-in calls etc.)
 
		return results;
	}
}

Remember: the Signature annotation needs classes, not simple objects! Kali-ma heavily relies on Java Reflection as provided by Java 1.5, so when you state that your procedure requires a String[], use String[].class in the annotation! That holds even when it means having to write ugly things like int.class or void.class.

Technically, you could even omit this information or even lie about it: since this is a runtime annotation, your plugin will compile anyhow, but you will most probably cause the wrath of the Goddess at runtime. So, please be so kind as to annotate your execute method implementation.

NeOn Toolkit users