001/* ----------------------------------------------------------------------------
002 * This file was automatically generated by SWIG (http://www.swig.org).
003 * Version 3.0.10
004 *
005 * Do not make changes to this file unless you know what you are doing--modify
006 * the SWIG interface file instead.
007 * ----------------------------------------------------------------------------- */
008
009package org.sbml.libsbml;
010
011/** 
012 * <span class="pkg-marker pkg-color-fbc"><a href="group__fbc.html">fbc</a></span>
013 An objective function for a flux.
014 <p>
015 * An integral component in a complete description of a steady-state model is
016 * the so-called <em>objective function</em>, which generally consists of a
017 * linear combination of model variables (fluxes) and a sense (direction). In
018 * the SBML Level&nbsp;3 <a href='../../../extensions-summary.html#fbc'>Flux Balance Constraints</a> (&ldquo;fbc&rdquo;) package, this concept
019 * is succinctly captured in the {@link Objective} class.  An {@link Objective} object
020 * includes a list of flux objectives, each in the form of a {@link FluxObjective}
021 * object.
022<p>
023 * The {@link FluxObjective} class is a relatively simple container for a model
024 * variable weighted by a signed linear coefficient.  In addition to the
025 * common SBML object attributes of 'id' and 'name' (both of which are
026 * optional), it adds two required attributes: 'reaction' and 'coefficient'.
027 <p>
028 * The 'reaction' attribute must have a value of type <code>SIdRef</code>,
029 * and its value is restricted to the identifier of a {@link Reaction} object in the
030 * model.  The 'reaction' attribute identifiers the reaction to which the
031 * {@link FluxObjective} applies.  The 'coefficient' attribute must have a value of
032 * type <code>double</code>, and refers to the coefficient that this
033 * {@link FluxObjective} takes in the enclosing {@link Objective}.  Its unit of measurement
034 * is <code>dimensionless</code>.  The meaning of these two attributes
035 * together is given by the formula <em>coefficient &times;
036 * reaction-flux</em>.  Since reactions in SBML Level&nbsp;3 are in units of
037 * <em>extent</em>, the units of a flux objective are thus <em>extent per
038 * time</em>.
039 <p>
040 * The following example * illustrates the use of these attributes in an
041 * example of a * ListOfObjectives:
042 * <pre class='fragment'>
043&lt;fbc:listOfObjectives fbc:activeObjective='obj1'&gt;
044 &lt;fbc:objective fbc:id='obj1' fbc:type='maximize'&gt;
045  &lt;fbc:listOfFluxObjectives&gt;
046   &lt;fbc:fluxObjective fbc:reaction='R1' fbc:coefficient='1'/&gt;
047   &lt;fbc:fluxObjective fbc:reaction='R2' fbc:coefficient='2'/&gt;
048  &lt;/fbc:listOfFluxObjectives&gt;
049 &lt;/fbc:objective&gt;
050&lt;/fbc:listOfObjectives&gt;
051</pre>
052 <p>
053 * @see Objective
054 * @see ListOfObjectives
055 * @see ListOfFluxObjectives
056 */
057
058public class FluxObjective extends SBase {
059   private long swigCPtr;
060
061   protected FluxObjective(long cPtr, boolean cMemoryOwn)
062   {
063     super(libsbmlJNI.FluxObjective_SWIGUpcast(cPtr), cMemoryOwn);
064     swigCPtr = cPtr;
065   }
066
067   protected static long getCPtr(FluxObjective obj)
068   {
069     return (obj == null) ? 0 : obj.swigCPtr;
070   }
071
072   protected static long getCPtrAndDisown (FluxObjective obj)
073   {
074     long ptr = 0;
075
076     if (obj != null)
077     {
078       ptr             = obj.swigCPtr;
079       obj.swigCMemOwn = false;
080     }
081
082     return ptr;
083   }
084
085  protected void finalize() {
086    delete();
087  }
088
089  public synchronized void delete() {
090    if (swigCPtr != 0) {
091      if (swigCMemOwn) {
092        swigCMemOwn = false;
093        libsbmlJNI.delete_FluxObjective(swigCPtr);
094      }
095      swigCPtr = 0;
096    }
097    super.delete();
098  }
099
100  
101/**
102   * Creates a new {@link FluxObjective} with the given SBML Level, Version, and
103   * &ldquo;fbc&rdquo;package version.
104   <p>
105   * @param level a long integer, the SBML Level to assign to this
106   * {@link FluxObjective}.
107   <p>
108   * @param version a long integer, the SBML Version to assign to this
109   * {@link FluxObjective}.
110   <p>
111   * @param pkgVersion a long integer, the SBML Fbc Version to assign to
112   * this {@link FluxObjective}.
113   <p>
114   * <p>
115 * @note Attempting to add an object to an {@link SBMLDocument} having a different
116 * combination of SBML Level, Version and XML namespaces than the object
117 * itself will result in an error at the time a caller attempts to make the
118 * addition.  A parent object must have compatible Level, Version and XML
119 * namespaces.  (Strictly speaking, a parent may also have more XML
120 * namespaces than a child, but the reverse is not permitted.)  The
121 * restriction is necessary to ensure that an SBML model has a consistent
122 * overall structure.  This requires callers to manage their objects
123 * carefully, but the benefit is increased flexibility in how models can be
124 * created by permitting callers to create objects bottom-up if desired.  In
125 * situations where objects are not yet attached to parents (e.g.,
126 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
127 * libSBML determine such things as whether it is valid to assign a
128 * particular value to an attribute.  For packages, this means that the 
129 * parent object to which this package element is being added must have
130 * been created with the package namespace, or that the package namespace
131 * was added to it, even if that parent is not a package object itself.
132   */ public
133 FluxObjective(long level, long version, long pkgVersion) throws org.sbml.libsbml.SBMLConstructorException {
134    this(libsbmlJNI.new_FluxObjective__SWIG_0(level, version, pkgVersion), true);
135  }
136
137  
138/**
139   * Creates a new {@link FluxObjective} with the given SBML Level, Version, and
140   * &ldquo;fbc&rdquo;package version.
141   <p>
142   * @param level a long integer, the SBML Level to assign to this
143   * {@link FluxObjective}.
144   <p>
145   * @param version a long integer, the SBML Version to assign to this
146   * {@link FluxObjective}.
147   <p>
148   * @param pkgVersion a long integer, the SBML Fbc Version to assign to
149   * this {@link FluxObjective}.
150   <p>
151   * <p>
152 * @note Attempting to add an object to an {@link SBMLDocument} having a different
153 * combination of SBML Level, Version and XML namespaces than the object
154 * itself will result in an error at the time a caller attempts to make the
155 * addition.  A parent object must have compatible Level, Version and XML
156 * namespaces.  (Strictly speaking, a parent may also have more XML
157 * namespaces than a child, but the reverse is not permitted.)  The
158 * restriction is necessary to ensure that an SBML model has a consistent
159 * overall structure.  This requires callers to manage their objects
160 * carefully, but the benefit is increased flexibility in how models can be
161 * created by permitting callers to create objects bottom-up if desired.  In
162 * situations where objects are not yet attached to parents (e.g.,
163 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
164 * libSBML determine such things as whether it is valid to assign a
165 * particular value to an attribute.  For packages, this means that the 
166 * parent object to which this package element is being added must have
167 * been created with the package namespace, or that the package namespace
168 * was added to it, even if that parent is not a package object itself.
169   */ public
170 FluxObjective(long level, long version) throws org.sbml.libsbml.SBMLConstructorException {
171    this(libsbmlJNI.new_FluxObjective__SWIG_1(level, version), true);
172  }
173
174  
175/**
176   * Creates a new {@link FluxObjective} with the given SBML Level, Version, and
177   * &ldquo;fbc&rdquo;package version.
178   <p>
179   * @param level a long integer, the SBML Level to assign to this
180   * {@link FluxObjective}.
181   <p>
182   * @param version a long integer, the SBML Version to assign to this
183   * {@link FluxObjective}.
184   <p>
185   * @param pkgVersion a long integer, the SBML Fbc Version to assign to
186   * this {@link FluxObjective}.
187   <p>
188   * <p>
189 * @note Attempting to add an object to an {@link SBMLDocument} having a different
190 * combination of SBML Level, Version and XML namespaces than the object
191 * itself will result in an error at the time a caller attempts to make the
192 * addition.  A parent object must have compatible Level, Version and XML
193 * namespaces.  (Strictly speaking, a parent may also have more XML
194 * namespaces than a child, but the reverse is not permitted.)  The
195 * restriction is necessary to ensure that an SBML model has a consistent
196 * overall structure.  This requires callers to manage their objects
197 * carefully, but the benefit is increased flexibility in how models can be
198 * created by permitting callers to create objects bottom-up if desired.  In
199 * situations where objects are not yet attached to parents (e.g.,
200 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
201 * libSBML determine such things as whether it is valid to assign a
202 * particular value to an attribute.  For packages, this means that the 
203 * parent object to which this package element is being added must have
204 * been created with the package namespace, or that the package namespace
205 * was added to it, even if that parent is not a package object itself.
206   */ public
207 FluxObjective(long level) throws org.sbml.libsbml.SBMLConstructorException {
208    this(libsbmlJNI.new_FluxObjective__SWIG_2(level), true);
209  }
210
211  
212/**
213   * Creates a new {@link FluxObjective} with the given SBML Level, Version, and
214   * &ldquo;fbc&rdquo;package version.
215   <p>
216   * @param level a long integer, the SBML Level to assign to this
217   * {@link FluxObjective}.
218   <p>
219   * @param version a long integer, the SBML Version to assign to this
220   * {@link FluxObjective}.
221   <p>
222   * @param pkgVersion a long integer, the SBML Fbc Version to assign to
223   * this {@link FluxObjective}.
224   <p>
225   * <p>
226 * @note Attempting to add an object to an {@link SBMLDocument} having a different
227 * combination of SBML Level, Version and XML namespaces than the object
228 * itself will result in an error at the time a caller attempts to make the
229 * addition.  A parent object must have compatible Level, Version and XML
230 * namespaces.  (Strictly speaking, a parent may also have more XML
231 * namespaces than a child, but the reverse is not permitted.)  The
232 * restriction is necessary to ensure that an SBML model has a consistent
233 * overall structure.  This requires callers to manage their objects
234 * carefully, but the benefit is increased flexibility in how models can be
235 * created by permitting callers to create objects bottom-up if desired.  In
236 * situations where objects are not yet attached to parents (e.g.,
237 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
238 * libSBML determine such things as whether it is valid to assign a
239 * particular value to an attribute.  For packages, this means that the 
240 * parent object to which this package element is being added must have
241 * been created with the package namespace, or that the package namespace
242 * was added to it, even if that parent is not a package object itself.
243   */ public
244 FluxObjective() throws org.sbml.libsbml.SBMLConstructorException {
245    this(libsbmlJNI.new_FluxObjective__SWIG_3(), true);
246  }
247
248  
249/**
250   * Creates a new {@link FluxObjective} with the given {@link FbcPkgNamespaces} object.
251   <p>
252   * <p>
253 * The package namespaces object used in this constructor is derived from a
254 * {@link SBMLNamespaces} object, which encapsulates SBML Level/Version/namespaces
255 * information.  It is used to communicate the SBML Level, Version, and 
256 * package version and name information used in addition to SBML Level&nbsp;3 Core.  A
257 * common approach to using libSBML's {@link SBMLNamespaces} facilities is to create an
258 * package namespace object somewhere in a program once, then hand that object
259 * as needed to object constructors of that package that accept it as and
260 * argument, such as this one.
261   <p>
262   * @param fbcns the {@link FbcPkgNamespaces} object.
263   <p>
264   * <p>
265 * @note Attempting to add an object to an {@link SBMLDocument} having a different
266 * combination of SBML Level, Version and XML namespaces than the object
267 * itself will result in an error at the time a caller attempts to make the
268 * addition.  A parent object must have compatible Level, Version and XML
269 * namespaces.  (Strictly speaking, a parent may also have more XML
270 * namespaces than a child, but the reverse is not permitted.)  The
271 * restriction is necessary to ensure that an SBML model has a consistent
272 * overall structure.  This requires callers to manage their objects
273 * carefully, but the benefit is increased flexibility in how models can be
274 * created by permitting callers to create objects bottom-up if desired.  In
275 * situations where objects are not yet attached to parents (e.g.,
276 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
277 * libSBML determine such things as whether it is valid to assign a
278 * particular value to an attribute.  For packages, this means that the 
279 * parent object to which this package element is being added must have
280 * been created with the package namespace, or that the package namespace
281 * was added to it, even if that parent is not a package object itself.
282   */ public
283 FluxObjective(FbcPkgNamespaces fbcns) throws org.sbml.libsbml.SBMLConstructorException {
284    this(libsbmlJNI.new_FluxObjective__SWIG_4(FbcPkgNamespaces.getCPtr(fbcns), fbcns), true);
285  }
286
287  
288/**
289   * Copy constructor for {@link FluxObjective}.
290   <p>
291   * @param orig the {@link FluxObjective} instance to copy.
292   */ public
293 FluxObjective(FluxObjective orig) throws org.sbml.libsbml.SBMLConstructorException {
294    this(libsbmlJNI.new_FluxObjective__SWIG_5(FluxObjective.getCPtr(orig), orig), true);
295  }
296
297  
298/**
299   * Creates and returns a deep copy of this {@link FluxObjective} object.
300   <p>
301   * @return a (deep) copy of this {@link FluxObjective} object.
302   */ public
303 FluxObjective cloneObject() {
304    long cPtr = libsbmlJNI.FluxObjective_cloneObject(swigCPtr, this);
305    return (cPtr == 0) ? null : new FluxObjective(cPtr, true);
306  }
307
308  
309/**
310   * Returns the value of the 'id' attribute of this {@link FluxObjective}.
311   <p>
312   * @note Because of the inconsistent behavior of this function with 
313   * respect to assignments and rules, it is now recommended to
314   * use the getIdAttribute() function instead.
315   <p>
316   * <p>
317 * The identifier given by an object's 'id' attribute value
318 * is used to identify the object within the SBML model definition.
319 * Other objects can refer to the component using this identifier.  The
320 * data type of 'id' is always <code>SId</code> or a type derived
321 * from that, such as <code>UnitSId</code>, depending on the object in 
322 * question.  All data types are defined as follows:
323 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
324 *   letter .= 'a'..'z','A'..'Z'
325 *   digit  .= '0'..'9'
326 *   idChar .= letter | digit | '_'
327 *   SId    .= ( letter | '_' ) idChar*
328 * </pre>
329 <p>
330 * The characters <code>(</code> and <code>)</code> are used for grouping, the
331 * character <code>*</code> 'zero or more times', and the character
332 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
333 * determined by an exact character sequence match; i.e., comparisons must be
334 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
335 * <code>SIdRef</code>, and derived types.
336 <p>
337 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
338 * moved to {@link SBase} directly, instead of being defined individually for many
339 * (but not all) objects.  Libsbml has for a long time provided functions
340 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
341 * would fail or otherwise return empty strings if executed on any object 
342 * for which those attributes were not defined.  Now that all {@link SBase} objects 
343 * define those attributes, those functions now succeed for any object with 
344 * the appropriate level and version.
345 <p>
346 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
347 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
348 * functions (though not the setId() or unsetId() functions) would instead 
349 * reference the value of the 'variable' attribute (for the rules and event 
350 * assignments) or the 'symbol' attribute (for initial assignments).  
351 * The {@link AlgebraicRule} fell into this category as well, though because it 
352 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
353 * always return an empty string, and isSetId() would always return <code>false.</code>
354 * For this reason, four new functions are now provided 
355 * (getIdAttribute(), setIdAttribute(String), 
356 * isSetIdAttribute(), and unsetIdAttribute()) that will always
357 * act on the actual 'id' attribute, regardless of the object's type.  The
358 * new functions should be used instead of the old ones unless the old behavior
359 * is somehow necessary.
360 <p>
361 * Regardless of the level and version of the SBML, these functions allow
362 * client applications to use more generalized code in some situations 
363 * (for instance, when manipulating objects that are all known to have 
364 * identifiers).  If the object in question does not posess an 'id' attribute 
365 * according to the SBML specification for the Level and Version in use,
366 * libSBML will not allow the identifier to be set, nor will it read or 
367 * write 'id' attributes for those objects.
368   <p>
369   * @return the id of this {@link FluxObjective}.
370   <p>
371   * @see #getIdAttribute()
372   * @see #setIdAttribute(String sid)
373   * @see #isSetIdAttribute()
374   * @see #unsetIdAttribute()
375   */ public
376 String getId() {
377    return libsbmlJNI.FluxObjective_getId(swigCPtr, this);
378  }
379
380  
381/**
382   * Returns the value of the 'name' attribute of this {@link FluxObjective} object.
383   <p>
384   * <p>
385 * <p>
386 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
387 * moved to {@link SBase} directly, instead of being defined individually for many
388 * (but not all) objects.  Libsbml has for a long time provided functions
389 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
390 * would fail or otherwise return empty strings if executed on any object 
391 * for which those attributes were not defined.  Now that all {@link SBase} objects 
392 * define those attributes, those functions now succeed for any object with 
393 * the appropriate level and version.
394 <p>
395 * The 'name' attribute is
396 * optional and is not intended to be used for cross-referencing purposes
397 * within a model.  Its purpose instead is to provide a human-readable
398 * label for the component.  The data type of 'name' is the type
399 * <code>string</code> defined in XML Schema.  SBML imposes no
400 * restrictions as to the content of 'name' attributes beyond those
401 * restrictions defined by the <code>string</code> type in XML Schema.
402 <p>
403 * The recommended practice for handling 'name' is as follows.  If a
404 * software tool has the capability for displaying the content of 'name'
405 * attributes, it should display this content to the user as a
406 * component's label instead of the component's 'id'.  If the user
407 * interface does not have this capability (e.g., because it cannot
408 * display or use special characters in symbol names), or if the 'name'
409 * attribute is missing on a given component, then the user interface
410 * should display the value of the 'id' attribute instead.  (Script
411 * language interpreters are especially likely to display 'id' instead of
412 * 'name'.)
413 <p>
414 * As a consequence of the above, authors of systems that automatically
415 * generate the values of 'id' attributes should be aware some systems
416 * may display the 'id''s to the user.  Authors therefore may wish to
417 * take some care to have their software create 'id' values that are: (a)
418 * reasonably easy for humans to type and read; and (b) likely to be
419 * meaningful, for example by making the 'id' attribute be an abbreviated
420 * form of the name attribute value.
421 <p>
422 * An additional point worth mentioning is although there are
423 * restrictions on the uniqueness of 'id' values, there are no
424 * restrictions on the uniqueness of 'name' values in a model.  This
425 * allows software applications leeway in assigning component identifiers.
426 <p>
427 * Regardless of the level and version of the SBML, these functions allow
428 * client applications to use more generalized code in some situations 
429 * (for instance, when manipulating objects that are all known to have 
430 * names).  If the object in question does not posess a 'name' attribute 
431 * according to the SBML specification for the Level and Version in use,
432 * libSBML will not allow the name to be set, nor will it read or 
433 * write 'name' attributes for those objects.
434 <p>
435 * @return the name of this SBML object, or the empty string if not set or unsettable.
436 <p>
437 * @see #getIdAttribute()
438 * @see #isSetName()
439 * @see #setName(String sid)
440 * @see #unsetName()
441   */ public
442 String getName() {
443    return libsbmlJNI.FluxObjective_getName(swigCPtr, this);
444  }
445
446  
447/**
448   * Returns the value of the 'reaction' attribute of this {@link FluxObjective}.
449   <p>
450   * @return the value of the 'reaction' attribute of this {@link FluxObjective} as a
451   * string.
452   */ public
453 String getReaction() {
454    return libsbmlJNI.FluxObjective_getReaction(swigCPtr, this);
455  }
456
457  
458/**
459   * Returns the value of the 'coefficient' attribute of this {@link FluxObjective}.
460   <p>
461   * @return the value of the 'coefficient' attribute of this {@link FluxObjective}
462   * as a double.
463   */ public
464 double getCoefficient() {
465    return libsbmlJNI.FluxObjective_getCoefficient(swigCPtr, this);
466  }
467
468  
469/**
470   * Predicate returning <code>true</code> if this {@link FluxObjective}'s 'id' attribute is
471   * set.
472   <p>
473   * <p>
474 * @note Because of the inconsistent behavior of this function with 
475 * respect to assignments and rules, it is now recommended to
476 * use the isSetIdAttribute() function instead.
477 <p>
478 * <p>
479 * The identifier given by an object's 'id' attribute value
480 * is used to identify the object within the SBML model definition.
481 * Other objects can refer to the component using this identifier.  The
482 * data type of 'id' is always <code>SId</code> or a type derived
483 * from that, such as <code>UnitSId</code>, depending on the object in 
484 * question.  All data types are defined as follows:
485 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
486 *   letter .= 'a'..'z','A'..'Z'
487 *   digit  .= '0'..'9'
488 *   idChar .= letter | digit | '_'
489 *   SId    .= ( letter | '_' ) idChar*
490 * </pre>
491 <p>
492 * The characters <code>(</code> and <code>)</code> are used for grouping, the
493 * character <code>*</code> 'zero or more times', and the character
494 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
495 * determined by an exact character sequence match; i.e., comparisons must be
496 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
497 * <code>SIdRef</code>, and derived types.
498 <p>
499 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
500 * moved to {@link SBase} directly, instead of being defined individually for many
501 * (but not all) objects.  Libsbml has for a long time provided functions
502 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
503 * would fail or otherwise return empty strings if executed on any object 
504 * for which those attributes were not defined.  Now that all {@link SBase} objects 
505 * define those attributes, those functions now succeed for any object with 
506 * the appropriate level and version.
507 <p>
508 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
509 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
510 * functions (though not the setId() or unsetId() functions) would instead 
511 * reference the value of the 'variable' attribute (for the rules and event 
512 * assignments) or the 'symbol' attribute (for initial assignments).  
513 * The {@link AlgebraicRule} fell into this category as well, though because it 
514 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
515 * always return an empty string, and isSetId() would always return <code>false.</code>
516 * For this reason, four new functions are now provided 
517 * (getIdAttribute(), setIdAttribute(String), 
518 * isSetIdAttribute(), and unsetIdAttribute()) that will always
519 * act on the actual 'id' attribute, regardless of the object's type.  The
520 * new functions should be used instead of the old ones unless the old behavior
521 * is somehow necessary.
522 <p>
523 * Regardless of the level and version of the SBML, these functions allow
524 * client applications to use more generalized code in some situations 
525 * (for instance, when manipulating objects that are all known to have 
526 * identifiers).  If the object in question does not posess an 'id' attribute 
527 * according to the SBML specification for the Level and Version in use,
528 * libSBML will not allow the identifier to be set, nor will it read or 
529 * write 'id' attributes for those objects.
530 <p>
531 * @return <code>true</code> if the 'id' attribute of this SBML object is
532 * set, <code>false</code> otherwise.
533 <p>
534 * @see #getIdAttribute()
535 * @see #setIdAttribute(String sid)
536 * @see #unsetIdAttribute()
537 * @see #isSetIdAttribute()
538   */ public
539 boolean isSetId() {
540    return libsbmlJNI.FluxObjective_isSetId(swigCPtr, this);
541  }
542
543  
544/**
545   * Predicate returning <code>true</code> if this {@link FluxObjective}'s 'name' attribute is
546   * set.
547   <p>
548   * <p>
549 * <p>
550 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
551 * moved to {@link SBase} directly, instead of being defined individually for many
552 * (but not all) objects.  Libsbml has for a long time provided functions
553 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
554 * would fail or otherwise return empty strings if executed on any object 
555 * for which those attributes were not defined.  Now that all {@link SBase} objects 
556 * define those attributes, those functions now succeed for any object with 
557 * the appropriate level and version.
558 <p>
559 * The 'name' attribute is
560 * optional and is not intended to be used for cross-referencing purposes
561 * within a model.  Its purpose instead is to provide a human-readable
562 * label for the component.  The data type of 'name' is the type
563 * <code>string</code> defined in XML Schema.  SBML imposes no
564 * restrictions as to the content of 'name' attributes beyond those
565 * restrictions defined by the <code>string</code> type in XML Schema.
566 <p>
567 * The recommended practice for handling 'name' is as follows.  If a
568 * software tool has the capability for displaying the content of 'name'
569 * attributes, it should display this content to the user as a
570 * component's label instead of the component's 'id'.  If the user
571 * interface does not have this capability (e.g., because it cannot
572 * display or use special characters in symbol names), or if the 'name'
573 * attribute is missing on a given component, then the user interface
574 * should display the value of the 'id' attribute instead.  (Script
575 * language interpreters are especially likely to display 'id' instead of
576 * 'name'.)
577 <p>
578 * As a consequence of the above, authors of systems that automatically
579 * generate the values of 'id' attributes should be aware some systems
580 * may display the 'id''s to the user.  Authors therefore may wish to
581 * take some care to have their software create 'id' values that are: (a)
582 * reasonably easy for humans to type and read; and (b) likely to be
583 * meaningful, for example by making the 'id' attribute be an abbreviated
584 * form of the name attribute value.
585 <p>
586 * An additional point worth mentioning is although there are
587 * restrictions on the uniqueness of 'id' values, there are no
588 * restrictions on the uniqueness of 'name' values in a model.  This
589 * allows software applications leeway in assigning component identifiers.
590 <p>
591 * Regardless of the level and version of the SBML, these functions allow
592 * client applications to use more generalized code in some situations 
593 * (for instance, when manipulating objects that are all known to have 
594 * names).  If the object in question does not posess a 'name' attribute 
595 * according to the SBML specification for the Level and Version in use,
596 * libSBML will not allow the name to be set, nor will it read or 
597 * write 'name' attributes for those objects.
598 <p>
599 * @return <code>true</code> if the 'name' attribute of this SBML object is
600 * set, <code>false</code> otherwise.
601 <p>
602 * @see #getName()
603 * @see #setName(String sid)
604 * @see #unsetName()
605   */ public
606 boolean isSetName() {
607    return libsbmlJNI.FluxObjective_isSetName(swigCPtr, this);
608  }
609
610  
611/**
612   * Predicate returning <code>true</code> if this {@link FluxObjective}'s 'reaction' attribute
613   * is set.
614   <p>
615   * @return <code>true</code> if this {@link FluxObjective}'s 'reaction' attribute has been set,
616   * otherwise <code>false</code> is returned.
617   */ public
618 boolean isSetReaction() {
619    return libsbmlJNI.FluxObjective_isSetReaction(swigCPtr, this);
620  }
621
622  
623/**
624   * Predicate returning <code>true</code> if this {@link FluxObjective}'s 'coefficient'
625   * attribute is set.
626   <p>
627   * @return <code>true</code> if this {@link FluxObjective}'s 'coefficient' attribute has been
628   * set, otherwise <code>false</code> is returned.
629   */ public
630 boolean isSetCoefficient() {
631    return libsbmlJNI.FluxObjective_isSetCoefficient(swigCPtr, this);
632  }
633
634  
635/**
636   * Sets the value of the 'id' attribute of this {@link FluxObjective}.
637   <p>
638   * <p>
639 * The string <code>sid</code> is copied.
640 <p>
641 * <p>
642 * The identifier given by an object's 'id' attribute value
643 * is used to identify the object within the SBML model definition.
644 * Other objects can refer to the component using this identifier.  The
645 * data type of 'id' is always <code>SId</code> or a type derived
646 * from that, such as <code>UnitSId</code>, depending on the object in 
647 * question.  All data types are defined as follows:
648 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
649 *   letter .= 'a'..'z','A'..'Z'
650 *   digit  .= '0'..'9'
651 *   idChar .= letter | digit | '_'
652 *   SId    .= ( letter | '_' ) idChar*
653 * </pre>
654 <p>
655 * The characters <code>(</code> and <code>)</code> are used for grouping, the
656 * character <code>*</code> 'zero or more times', and the character
657 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
658 * determined by an exact character sequence match; i.e., comparisons must be
659 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
660 * <code>SIdRef</code>, and derived types.
661 <p>
662 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
663 * moved to {@link SBase} directly, instead of being defined individually for many
664 * (but not all) objects.  Libsbml has for a long time provided functions
665 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
666 * would fail or otherwise return empty strings if executed on any object 
667 * for which those attributes were not defined.  Now that all {@link SBase} objects 
668 * define those attributes, those functions now succeed for any object with 
669 * the appropriate level and version.
670 <p>
671 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
672 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
673 * functions (though not the setId() or unsetId() functions) would instead 
674 * reference the value of the 'variable' attribute (for the rules and event 
675 * assignments) or the 'symbol' attribute (for initial assignments).  
676 * The {@link AlgebraicRule} fell into this category as well, though because it 
677 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
678 * always return an empty string, and isSetId() would always return <code>false.</code>
679 * For this reason, four new functions are now provided 
680 * (getIdAttribute(), setIdAttribute(String), 
681 * isSetIdAttribute(), and unsetIdAttribute()) that will always
682 * act on the actual 'id' attribute, regardless of the object's type.  The
683 * new functions should be used instead of the old ones unless the old behavior
684 * is somehow necessary.
685 <p>
686 * Regardless of the level and version of the SBML, these functions allow
687 * client applications to use more generalized code in some situations 
688 * (for instance, when manipulating objects that are all known to have 
689 * identifiers).  If the object in question does not posess an 'id' attribute 
690 * according to the SBML specification for the Level and Version in use,
691 * libSBML will not allow the identifier to be set, nor will it read or 
692 * write 'id' attributes for those objects.
693 <p>
694 * @param sid the string to use as the identifier of this object.
695 <p>
696 * <p>
697 * @return integer value indicating success/failure of the
698 * function.   The possible values
699 * returned by this function are:
700 * <ul>
701 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
702 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
703 * <li> {@link libsbmlConstants#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE}
704 *
705 * </ul> <p>
706 * @see #getIdAttribute()
707 * @see #setIdAttribute(String sid)
708 * @see #isSetIdAttribute()
709 * @see #unsetIdAttribute()
710   */ public
711 int setId(String sid) {
712    return libsbmlJNI.FluxObjective_setId(swigCPtr, this, sid);
713  }
714
715  
716/**
717   * Sets the value of the 'name' attribute of this {@link FluxObjective}.
718   <p>
719   * <p>
720 * The string in <code>name</code> is copied.
721 <p>
722 * @param name the new name for the SBML object.
723 <p>
724 * <p>
725 * @return integer value indicating success/failure of the
726 * function.   The possible values
727 * returned by this function are:
728 * <ul>
729 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
730 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
731 *
732 * </ul>
733   */ public
734 int setName(String name) {
735    return libsbmlJNI.FluxObjective_setName(swigCPtr, this, name);
736  }
737
738  
739/**
740   * Sets the value of the 'reaction' attribute of this {@link FluxObjective}.
741   <p>
742   * @param reaction the value of the 'reaction' attribute to be set.
743   <p>
744   * <p>
745 * @return integer value indicating success/failure of the
746 * function.   The possible values
747 * returned by this function are:
748   * <ul>
749   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
750   * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
751   * </ul>
752   */ public
753 int setReaction(String reaction) {
754    return libsbmlJNI.FluxObjective_setReaction(swigCPtr, this, reaction);
755  }
756
757  
758/**
759   * Sets the value of the 'coefficient' attribute of this {@link FluxObjective}.
760   <p>
761   * @param coefficient the value of the 'coefficient' attribute to be set.
762   <p>
763   * <p>
764 * @return integer value indicating success/failure of the
765 * function.   The possible values
766 * returned by this function are:
767   * <ul>
768   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
769   * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
770   * </ul>
771   */ public
772 int setCoefficient(double coefficient) {
773    return libsbmlJNI.FluxObjective_setCoefficient(swigCPtr, this, coefficient);
774  }
775
776  
777/**
778   * Unsets the value of the 'id' attribute of this {@link FluxObjective}.
779   <p>
780   * <p>
781 * <p>
782 * The identifier given by an object's 'id' attribute value
783 * is used to identify the object within the SBML model definition.
784 * Other objects can refer to the component using this identifier.  The
785 * data type of 'id' is always <code>SId</code> or a type derived
786 * from that, such as <code>UnitSId</code>, depending on the object in 
787 * question.  All data types are defined as follows:
788 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
789 *   letter .= 'a'..'z','A'..'Z'
790 *   digit  .= '0'..'9'
791 *   idChar .= letter | digit | '_'
792 *   SId    .= ( letter | '_' ) idChar*
793 * </pre>
794 <p>
795 * The characters <code>(</code> and <code>)</code> are used for grouping, the
796 * character <code>*</code> 'zero or more times', and the character
797 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
798 * determined by an exact character sequence match; i.e., comparisons must be
799 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
800 * <code>SIdRef</code>, and derived types.
801 <p>
802 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
803 * moved to {@link SBase} directly, instead of being defined individually for many
804 * (but not all) objects.  Libsbml has for a long time provided functions
805 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
806 * would fail or otherwise return empty strings if executed on any object 
807 * for which those attributes were not defined.  Now that all {@link SBase} objects 
808 * define those attributes, those functions now succeed for any object with 
809 * the appropriate level and version.
810 <p>
811 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
812 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
813 * functions (though not the setId() or unsetId() functions) would instead 
814 * reference the value of the 'variable' attribute (for the rules and event 
815 * assignments) or the 'symbol' attribute (for initial assignments).  
816 * The {@link AlgebraicRule} fell into this category as well, though because it 
817 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
818 * always return an empty string, and isSetId() would always return <code>false.</code>
819 * For this reason, four new functions are now provided 
820 * (getIdAttribute(), setIdAttribute(String), 
821 * isSetIdAttribute(), and unsetIdAttribute()) that will always
822 * act on the actual 'id' attribute, regardless of the object's type.  The
823 * new functions should be used instead of the old ones unless the old behavior
824 * is somehow necessary.
825 <p>
826 * Regardless of the level and version of the SBML, these functions allow
827 * client applications to use more generalized code in some situations 
828 * (for instance, when manipulating objects that are all known to have 
829 * identifiers).  If the object in question does not posess an 'id' attribute 
830 * according to the SBML specification for the Level and Version in use,
831 * libSBML will not allow the identifier to be set, nor will it read or 
832 * write 'id' attributes for those objects.
833 <p>
834 * <p>
835 * @return integer value indicating success/failure of the
836 * function.   The possible values
837 * returned by this function are:
838 * <ul>
839 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
840 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
841 *
842 * </ul> <p>
843 * @see #getIdAttribute()
844 * @see #setIdAttribute(String sid)
845 * @see #isSetIdAttribute()
846 * @see #unsetIdAttribute()
847   */ public
848 int unsetId() {
849    return libsbmlJNI.FluxObjective_unsetId(swigCPtr, this);
850  }
851
852  
853/**
854   * Unsets the value of the 'name' attribute of this {@link FluxObjective}.
855   <p>
856   * <p>
857 * <p>
858 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
859 * moved to {@link SBase} directly, instead of being defined individually for many
860 * (but not all) objects.  Libsbml has for a long time provided functions
861 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
862 * would fail or otherwise return empty strings if executed on any object 
863 * for which those attributes were not defined.  Now that all {@link SBase} objects 
864 * define those attributes, those functions now succeed for any object with 
865 * the appropriate level and version.
866 <p>
867 * The 'name' attribute is
868 * optional and is not intended to be used for cross-referencing purposes
869 * within a model.  Its purpose instead is to provide a human-readable
870 * label for the component.  The data type of 'name' is the type
871 * <code>string</code> defined in XML Schema.  SBML imposes no
872 * restrictions as to the content of 'name' attributes beyond those
873 * restrictions defined by the <code>string</code> type in XML Schema.
874 <p>
875 * The recommended practice for handling 'name' is as follows.  If a
876 * software tool has the capability for displaying the content of 'name'
877 * attributes, it should display this content to the user as a
878 * component's label instead of the component's 'id'.  If the user
879 * interface does not have this capability (e.g., because it cannot
880 * display or use special characters in symbol names), or if the 'name'
881 * attribute is missing on a given component, then the user interface
882 * should display the value of the 'id' attribute instead.  (Script
883 * language interpreters are especially likely to display 'id' instead of
884 * 'name'.)
885 <p>
886 * As a consequence of the above, authors of systems that automatically
887 * generate the values of 'id' attributes should be aware some systems
888 * may display the 'id''s to the user.  Authors therefore may wish to
889 * take some care to have their software create 'id' values that are: (a)
890 * reasonably easy for humans to type and read; and (b) likely to be
891 * meaningful, for example by making the 'id' attribute be an abbreviated
892 * form of the name attribute value.
893 <p>
894 * An additional point worth mentioning is although there are
895 * restrictions on the uniqueness of 'id' values, there are no
896 * restrictions on the uniqueness of 'name' values in a model.  This
897 * allows software applications leeway in assigning component identifiers.
898 <p>
899 * Regardless of the level and version of the SBML, these functions allow
900 * client applications to use more generalized code in some situations 
901 * (for instance, when manipulating objects that are all known to have 
902 * names).  If the object in question does not posess a 'name' attribute 
903 * according to the SBML specification for the Level and Version in use,
904 * libSBML will not allow the name to be set, nor will it read or 
905 * write 'name' attributes for those objects.
906 <p>
907 * <p>
908 * @return integer value indicating success/failure of the
909 * function.   The possible values
910 * returned by this function are:
911 * <ul>
912 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
913 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
914 *
915 * </ul> <p>
916 * @see #getName()
917 * @see #setName(String sid)
918 * @see #isSetName()
919   */ public
920 int unsetName() {
921    return libsbmlJNI.FluxObjective_unsetName(swigCPtr, this);
922  }
923
924  
925/**
926   * Unsets the value of the 'reaction' attribute of this {@link FluxObjective}.
927   <p>
928   * <p>
929 * @return integer value indicating success/failure of the
930 * function.   The possible values
931 * returned by this function are:
932   * <ul>
933   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
934   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
935   * </ul>
936   */ public
937 int unsetReaction() {
938    return libsbmlJNI.FluxObjective_unsetReaction(swigCPtr, this);
939  }
940
941  
942/**
943   * Unsets the value of the 'coefficient' attribute of this {@link FluxObjective}.
944   <p>
945   * <p>
946 * @return integer value indicating success/failure of the
947 * function.   The possible values
948 * returned by this function are:
949   * <ul>
950   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
951   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
952   * </ul>
953   */ public
954 int unsetCoefficient() {
955    return libsbmlJNI.FluxObjective_unsetCoefficient(swigCPtr, this);
956  }
957
958  
959/**
960   * <p>
961 * Replaces all uses of a given <code>SIdRef</code> type attribute value with another
962 * value.
963 <p>
964 * <p>
965 * In SBML, object identifiers are of a data type called <code>SId</code>.
966 * In SBML Level&nbsp;3, an explicit data type called <code>SIdRef</code> was
967 * introduced for attribute values that refer to <code>SId</code> values; in
968 * previous Levels of SBML, this data type did not exist and attributes were
969 * simply described to as 'referring to an identifier', but the effective
970 * data type was the same as <code>SIdRef</code> in Level&nbsp;3.  These and
971 * other methods of libSBML refer to the type <code>SIdRef</code> for all
972 * Levels of SBML, even if the corresponding SBML specification did not
973 * explicitly name the data type.
974 <p>
975 * This method works by looking at all attributes and (if appropriate)
976 * mathematical formulas in MathML content, comparing the referenced
977 * identifiers to the value of <code>oldid</code>.  If any matches are found, the
978 * matching values are replaced with <code>newid</code>.  The method does <em>not</em>
979 * descend into child elements.
980 <p>
981 * @param oldid the old identifier.
982 * @param newid the new identifier.
983   */ public
984 void renameSIdRefs(String oldid, String newid) {
985    libsbmlJNI.FluxObjective_renameSIdRefs(swigCPtr, this, oldid, newid);
986  }
987
988  
989/**
990   * Returns the XML element name of this object.
991   <p>
992   * For {@link FluxObjective}, the XML element name is always <code>'fluxObjective'.</code>
993   <p>
994   * @return the name of this element, i.e. <code>'fluxObjective'.</code>
995   */ public
996 String getElementName() {
997    return libsbmlJNI.FluxObjective_getElementName(swigCPtr, this);
998  }
999
1000  
1001/**
1002   * Returns the libSBML type code for this SBML object.
1003   <p>
1004   * <p>
1005 * LibSBML attaches an identifying code to every kind of SBML object.  These
1006 * are integer constants known as <em>SBML type codes</em>.  The names of all
1007 * the codes begin with the characters <code>SBML_</code>.
1008 * In the Java language interface for libSBML, the
1009 * type codes are defined as static integer constants in the interface class
1010 * {@link libsbmlConstants}.    Note that different Level&nbsp;3
1011 * package plug-ins may use overlapping type codes; to identify the package
1012 * to which a given object belongs, call the <code>getPackageName()</code>
1013 * method on the object.
1014   <p>
1015   * @return the SBML type code for this object:
1016   * {@link libsbmlConstants#SBML_FBC_FLUXOBJECTIVE SBML_FBC_FLUXOBJECTIVE} (default).
1017   <p>
1018   * <p>
1019 * @warning <span class='warning'>The specific integer values of the possible
1020 * type codes may be reused by different libSBML plug-ins for SBML Level&nbsp;3.
1021 * packages,  To fully identify the correct code, <strong>it is necessary to
1022 * invoke both getTypeCode() and getPackageName()</strong>.</span>
1023   <p>
1024   * @see #getElementName()
1025   * @see #getPackageName()
1026   */ public
1027 int getTypeCode() {
1028    return libsbmlJNI.FluxObjective_getTypeCode(swigCPtr, this);
1029  }
1030
1031  
1032/**
1033   * Predicate returning <code>true</code> if all the required attributes
1034   * for this {@link FluxObjective} object have been set.
1035   <p>
1036   * @note The required attributes for a {@link FluxObjective} object are:
1037   * <ul>
1038   * <li> 'reaction'
1039   * <li> 'coefficient'
1040   *
1041   * </ul> <p>
1042   * @return a boolean value indicating whether all the required
1043   * attributes for this object have been defined.
1044   */ public
1045 boolean hasRequiredAttributes() {
1046    return libsbmlJNI.FluxObjective_hasRequiredAttributes(swigCPtr, this);
1047  }
1048
1049  
1050/** * @internal */ public
1051 void enablePackageInternal(String pkgURI, String pkgPrefix, boolean flag) {
1052    libsbmlJNI.FluxObjective_enablePackageInternal(swigCPtr, this, pkgURI, pkgPrefix, flag);
1053  }
1054
1055}