A problem represents infeasibilities, alerts and warnings in the plan. More...

#include <model.h>

Inheritance diagram for frepple::Problem:

List of all members.

Classes

class  const_iterator
 This class models an STL-like iterator that allows us to iterate over the named entities in a simple and safe way. More...
class  List
 This auxilary class is used to maintain a list of problem models. More...

Public Member Functions

void endElement (XMLInput &, const Attribute &, const DataElement &)
PyObject * getattro (const Attribute &)
virtual const DateRange getDates () const =0
virtual string getDescription () const =0
virtual string getEntity () const =0
virtual ObjectgetOwner () const =0
virtual const MetaClassgetType () const
virtual double getWeight () const =0
virtual bool isFeasible () const =0
 Problem (HasProblems *p=NULL)
PyObject * str () const
virtual void writeElement (XMLOutput *, const Keyword &, mode=DEFAULT) const
virtual ~Problem ()

Static Public Member Functions

static const_iterator begin ()
static const_iterator begin (HasProblems *, bool=true)
static void clearProblems ()
static void clearProblems (HasProblems &p, bool setchanged=true)
static const const_iterator end ()
static int initialize ()
static void writer (const MetaCategory *, XMLOutput *)

Static Public Attributes

static const MetaCategorymetadata

Protected Member Functions

void addProblem ()
bool operator< (const Problem &a) const
void removeProblem ()

Protected Attributes

ProblemnextProblem
HasProblemsowner

Friends

class const_iterator
class List

Detailed Description

A problem represents infeasibilities, alerts and warnings in the plan.

Problems are maintained internally by the system. They are thus only exported, meaning that you can't directly import or create problems.
This class is the pure virtual base class for all problem types.
The usage of the problem objects is based on the following principles:

  • Problems objects are passive. They don't actively change the model state.
  • Objects of the HasProblems class actively create and destroy Problem objects.
  • Problem objects are managed in a 'lazy' way, meaning they only are getting created when the list of problems is requested by the user.
    During normal planning activities we merely mark the planning entities that have changed, so we can easily pick up which entities to recompute the problems for. In this way we can avoid the cpu and memory overhead of keeping the problem list up to date at all times, while still providing the user with the correct list of problems when required.
  • Given the above, Problems are lightweight objects that consume limited memory.

Definition at line 600 of file model.h.


Constructor & Destructor Documentation

frepple::Problem::Problem ( HasProblems p = NULL) [inline, explicit]

Constructor.
Note that this method can't manipulate the problem container, since the problem objects aren't fully constructed yet.

See also:
addProblem

Definition at line 613 of file model.h.

virtual frepple::Problem::~Problem ( ) [inline, virtual]

Destructor.

See also:
removeProblem

Definition at line 622 of file model.h.


Member Function Documentation

void frepple::Problem::addProblem ( ) [protected]

Adds a newly created problem to the problem container. This method needs to be called in the constructor of a problem subclass. It can't be called from the constructor of the base Problem class, since the object isn't fully created yet and thus misses the proper information used by the compare method.

See also:
removeProblem

Definition at line 108 of file problem.cpp.

Problem::const_iterator frepple::Problem::begin ( ) [static]

Returns an iterator to the very first problem. The iterator can be incremented till it points past the very last problem.

Definition at line 511 of file problem.cpp.

Problem::const_iterator frepple::Problem::begin ( HasProblems i,
bool  refresh = true 
) [static]

Return an iterator to the first problem of this entity. The iterator can be incremented till it points past the last problem of this plannable entity.
The boolean argument specifies whether the problems need to be recomputed as part of this method.

Definition at line 518 of file problem.cpp.

void frepple::Problem::clearProblems ( ) [static]

Erases the list of all problems. This methods can be used reduce the memory consumption at critical points. The list of problems will be recreated when the problem detection is triggered again.

Definition at line 237 of file problem.cpp.

void frepple::Problem::clearProblems ( HasProblems p,
bool  setchanged = true 
) [static]

Erases the list of problems linked with a certain plannable object.
If the second parameter is set to true, the problems will be recreated when the next problem detection round is triggered.

Definition at line 249 of file problem.cpp.

const Problem::const_iterator frepple::Problem::end ( ) [static]

Return an iterator pointing beyond the last problem.

Definition at line 529 of file problem.cpp.

void frepple::Problem::endElement ( XMLInput ,
const Attribute ,
const DataElement  
) [inline, virtual]

Called while restoring the model from an XML-file.
This is called when the corresponding close element tag is encountered, and the Data() member of pElement is valid.

Implements frepple::utils::Object.

Definition at line 647 of file model.h.

PyObject * frepple::Problem::getattro ( const Attribute attr) [virtual]

Default getattro method.
Subclasses are expected to implement an override if the type supports gettattro.

Reimplemented from frepple::utils::PythonExtensionBase.

Definition at line 535 of file problem.cpp.

virtual double frepple::Problem::getWeight ( ) const [pure virtual]
int frepple::Problem::initialize ( ) [static]

Initialize the class.

Definition at line 51 of file problem.cpp.

virtual bool frepple::Problem::isFeasible ( ) const [pure virtual]

Returns true if the plan remains feasible even if it contains this problem, i.e. if the problems flags only a warning. Returns false if a certain problem points at an infeasibility of the plan.

Implemented in frepple::ProblemMaterialExcess, frepple::ProblemMaterialShortage, frepple::ProblemCapacityUnderload, frepple::ProblemCapacityOverload, frepple::ProblemExcess, frepple::ProblemShort, frepple::ProblemInvalidData, frepple::ProblemEarly, frepple::ProblemLate, frepple::ProblemDemandNotPlanned, frepple::ProblemPrecedence, frepple::ProblemBeforeFence, and frepple::ProblemBeforeCurrent.

bool frepple::Problem::operator< ( const Problem a) const [protected]

Comparison of 2 problems.
To garantuee that the problems are sorted in a consistent and stable way, the following sorting criteria are used (in order of priority):

  1. Entity
    This sort is to be ensured by the client. This method can't compare problems of different entities!
  2. Type
    Each problem type has a hashcode used for sorting.
  3. Start date

The sorting is expected such that it can be used as a key, i.e. no two problems of will ever evaluate to be identical.

Definition at line 95 of file problem.cpp.

void frepple::Problem::removeProblem ( ) [protected]

Removes a problem from the problem container. This method needs to be called from the destructor of a problem subclass.
Due to the single linked list data structure, this methods' performance is linear with the number of problems of an entity. This is acceptable since we don't expect entities with a huge amount of problems.

See also:
addproblem

Definition at line 134 of file problem.cpp.

PyObject* frepple::Problem::str ( ) const [inline, virtual]

Default str method.
Subclasses are expected to implement an override if the type supports conversion to a string.

Reimplemented from frepple::utils::PythonExtensionBase.

Definition at line 652 of file model.h.

void frepple::Problem::writeElement ( XMLOutput ,
const Keyword ,
mode  = DEFAULT 
) const [virtual]

Called while writing the model into an XML-file. The user class should write itself out, using the IOutStream members for its "simple" members and calling writeElement recursively for any contained objects. Not all classes are expected to implement this method. In instances of such a class can be created but can't be persisted. E.g. Command

Reimplemented from frepple::utils::Object.

Definition at line 285 of file problem.cpp.

void frepple::Problem::writer ( const MetaCategory c,
XMLOutput o 
) [static]

Definition at line 269 of file problem.cpp.


Friends And Related Function Documentation

friend class const_iterator [friend]

Definition at line 603 of file model.h.

friend class List [friend]

Definition at line 605 of file model.h.


Member Data Documentation

Each Problem contains a pointer to the next pointer for the same owner. This class implements thus an intrusive single linked list of Problem objects.

Definition at line 700 of file model.h.

Each Problem object references a HasProblem object as its owner.

Definition at line 695 of file model.h.


The documentation for this class was generated from the following files:

Documentation generated for frePPLe by  doxygen