Standards for Component Functionality - Revision history

Dvernon at 08:24, 17 February 2015

2015-02-17T08:24:59Z

Dvernon at 08:22, 17 February 2015

2015-02-17T08:22:46Z

Dvernon: Dvernon moved page Mandatory Standards for Component Functionality to Standards for Component Functionality

2015-02-15T12:22:33Z

Dvernon moved page Mandatory Standards for Component Functionality to Standards for Component Functionality

Dvernon at 16:35, 6 November 2014

2014-11-06T16:35:23Z

Dvernon: /* Component Computation Standards */

2014-08-29T10:38:36Z

‎Component Computation Standards

Dvernon: /* Component Computation Standards */

2014-08-29T10:38:22Z

‎Component Computation Standards

Dvernon: /* Component Port Names */

2014-08-29T10:37:25Z

‎Component Port Names

Dvernon: /* Introduction */

2014-08-29T10:36:55Z

‎Introduction

Dvernon: /* Component Computation Standards */

2014-08-29T10:35:51Z

‎Component Computation Standards

Dvernon: /* Component Coordination Standards */

2014-08-29T10:35:35Z

‎Component Coordination Standards

@@ Line 1: / Line 1: @@
 == Introduction ==
-The standards set out in this section are concerned with adherence to the principles of the 4Cs of Configuration, Coordination, Computation, and Communication in Component-Base Software Engineering (CBSE). By their very nature, these standards are closely tied to the implementation of the software and the YARP support for that implementation. However, this is not an appropriate place to provide a detailed guide to component-based software development and that will be documented in due course on the DREAM wiki. On the other hand, we will make detailed reference to specific YARP-based implementation techniques in the following in order to make clear that the standards entail both abstract requirements and specific implementation techniques. To see how all this works together, you should refer to the complete example implementation of a prototypical component <code>protoComponent</code> elsewhere on the DREAM wiki.
+The standards set out in this section are concerned with adherence to the principles of the 4Cs of Configuration, Coordination, Computation, and Communication in Component-Base Software Engineering (CBSE). By their very nature, these standards are closely tied to the implementation of the software and the YARP support for that implementation. However, this is not an appropriate place to provide a detailed guide to component-based software development and that will be documented in due course on the CINDY wiki. On the other hand, we will make detailed reference to specific YARP-based implementation techniques in the following in order to make clear that the standards entail both abstract requirements and specific implementation techniques. To see how all this works together, you should refer to the complete example implementation of a prototypical component <code>protoComponent</code> elsewhere on the CINDY wiki.
@@ Line 7: / Line 7: @@
-First, to develop a component for DREAM you need to define two derived classes:
+First, to develop a component for CINDY you need to define two derived classes:
 * The first class is derived from the <code>yarp::os::RFModule class</code>:
@@ Line 101: / Line 101: @@
 YARP uses a policy file to determine the paths to search for configuration files. This requires you to tell YARP where to look for the information required to initialize the root of the path to use when searching for component configuration files (in fact, YARP allows for several default paths, as described below). This is accomplished with the <code>configure()</code> method in the <code>ResourceFinder</code> class, as follows.
-    rf.configure("DREAM_ROOT", argc, argv);
+    rf.configure("CINDY_ROOT", argc, argv);
-<code>DREAM_ROOT</code> is an environment variable (which you need to define and initialize). Its value is the path where a configuration file named <code>DREAM_ROOT.ini</code> is located (e.g. <code>C:\DREAM</code>). This <code>.ini</code> file contains the YARP policies for finding DREAM configuration files. It defines two parameters <code>capability_directory</code> and <code>default_capability</code>.
+<code>CINDY_ROOT</code> is an environment variable (which you need to define and initialize). Its value is the path where a configuration file named <code>CINDY_ROOT.ini</code> is located (e.g. <code>C:\CINDY</code>). This <code>.ini</code> file contains the YARP policies for finding CINDY configuration files. It defines two parameters <code>capability_directory</code> and <code>default_capability</code>.
-<code>capability_directory</code> has one value associated with it: the path that is appended to the value of the <code>DREAM_ROOT</code> environment variable. For example, if we had
+<code>capability_directory</code> has one value associated with it: the path that is appended to the value of the <code>CINDY_ROOT</code> environment variable. For example, if we had
   capability_directory Release
-then the default path would begin <code>C:/DREAM/Release</code> (by concatenating values associated with <code>DREAM_ROOT</code> and <code>capability_directory</code>.
+then the default path would begin <code>C:/CINDY/Release</code> (by concatenating values associated with <code>CINDY_ROOT</code> and <code>capability_directory</code>.
@@ Line 119: / Line 119: @@
 then the paths to be searched would be
-  C:/DREAM/Release/config
+  C:/CINDY/Release/config
-  C:/DREAM/Release/components/config
+  C:/CINDY/Release/components/config
 YARP also searches one other path (and, in fact, it searches it first). This path is the one that is formed by appending the value of the default context provided as an argument of the <code>rf.setDefaultContext()</code> method (described above) or the value of the <code>--context</code> parameter in an application. For example, if a component set the default context as follows
@@ Line 132: / Line 132: @@
 then YARP would first search for the configuration file in
-  C:/DREAM/Release/components/protoComponent/config
+  C:/CINDY/Release/components/protoComponent/config
 before then searching
-  C:/DREAM/Release/config
+  C:/CINDY/Release/config
-  C:/DREAM/Release/components/config
+  C:/CINDY/Release/components/config
-as dictated by the YARP policies in the <code>DREAM_ROOT.ini</code> configuration file.
+as dictated by the YARP policies in the <code>CINDY_ROOT.ini</code> configuration file.
 ===User-defined Configuration File===

← Older revision		Revision as of 08:22, 17 February 2015
Line 265:		Line 265:

	A component must effect all communication with other component using YARP ports. Examples of port usage are provided in the <code>protoComponent</code> example.		A component must effect all communication with other component using YARP ports. Examples of port usage are provided in the <code>protoComponent</code> example.
		+
		+
		+	----
		+	Return to [[The CINDY Cognitive Architecture]] main page.

@@ Line 150: / Line 150: @@
 ===Component Parameters===
-As stated above, a component must read its key-value parameters from a <code>.ini<code> configuration file named after the component, e.g. <code>protoComponent.ini</code>.
+As stated above, a component must read its key-value parameters from a <code>.ini</code> configuration file named after the component, e.g. <code>protoComponent.ini</code>.
@@ Line 214: / Line 214: @@
-The following code segment shows how the <code respond()</code> method in the resource finder <code>RFModule</code> class handles input from this port.
+The following code segment shows how the <code>respond()</code> method in the resource finder <code>RFModule</code> class handles input from this port.

@@ Line 256: / Line 256: @@
   protoComponentThread->start(); // this calls threadInit() and
-                               // it if returns true, it then calls run()
+                                // it if returns true, it then calls run()
 * The derived class methods are defined in <code>protoComponentComputation.cpp<code>.

@@ Line 251: / Line 251: @@
 * It is instantiated as an object and processing started in the overloaded <code>RFModule</code> method <code>configure()</code> in the configuration file, e.g. <code>protoComponentConfiguration.cpp</code>, viz.
-        protoComponentThread = new ProtoComponentThread(&imageIn,
+ protoComponentThread = new ProtoComponentThread(&imageIn,
-                                                        &imageOut,
+                                                 &imageOut,
-                                                        &thresholdValue);
+                                                 &thresholdValue);
-        protoComponentThread->start(); // this calls threadInit() and
+ protoComponentThread->start(); // this calls threadInit() and
-                                         // it if returns true, it then calls run()
+                               // it if returns true, it then calls run()
 * The derived class methods are defined in <code>protoComponentComputation.cpp<code>.

← Older revision	Revision as of 12:22, 15 February 2015
(No difference)

@@ Line 168: / Line 168: @@
   /* get the name of the input and output ports, automatically prefixing */
   /* the module name by using getName()                                  */
-−
   inputPortName = "/";

← Older revision		Revision as of 10:36, 29 August 2014
Line 29:		Line 29:

	/* create your module */		/* create your module */
		+
	ProtoComponent protoComponent;		ProtoComponent protoComponent;

@@ Line 253: / Line 253: @@
                                                          &imageOut,
                                                          &thresholdValue);
-−
          protoComponentThread->start(); // this calls threadInit() and
                                           // it if returns true, it then calls run()
@@ Line 260: / Line 260: @@
 All parameters read and initialized in the <code>configure()</code> method of the <code>yarp::os::RFModule</code> class must be passed explicitly when instantiating the derived <code>yarp::os::Thread</code> or <code>yarp::os::RateThread</code> object. For example, <code>imageIn</code>, <code>imageOut</code>, and <code>thresholdValue</code> arguments above are all initialized with the <code>rf.check()</code> method.
 ==Component Communication Standards==
 A component must effect all communication with other component using YARP ports. Examples of port usage are provided in the <code>protoComponent</code> example.

@@ Line 218: / Line 218: @@
 This code is to be included in the configuration <code>.cpp</code> file, e.g. <code>protoComponentConfiguration.cpp</code>.
-  bool protoComponent::respond(const Bottle& command, Bottle& reply)
+  bool protoComponent::respond(const Bottle& command, Bottle& reply) {
-−
      string helpMessage =  string(getName().c_str()) +
                                   " commands are: \n" +
@@ Line 243: / Line 242: @@
     return true;
+  }
 == Component Computation Standards ==