Home >> All

•	feynman.framework.* (24)	•	feynman.framework.controller.* (2)	•	feynman.framework.datastore.* (6)
•	feynman.framework.simulation.* (3)	•	feynman.framework.system.* (13)

Package Samples:

• feynman.framework.controller
• feynman.framework.datastore
• feynman.framework.simulation
• feynman.framework.system

Classes:

• Controller: This class sets up the simulation from the properties file and then runs it based on the configuration classes. The main method of this class executes the steps of the simulation. The main method of this class is defined as the executable in the manifest file. The main steps to running a simulation are as follows: Write the source for a sub-class of PhysicalObject i.e. develop a class that sub-classes CartesianObject if you are working in the Cartesian coordinate system. Write the source classes that implement the PhysicalConfiguration, PhysicalAlgorithm, PhysicalMeasurement interfaces. Setup the ...
• PhysicalMeasurement: This interface defines the required method for the Measurement bean. The user will define the necessary get and set methods for the bean on the quantities that are being measured as in the following example: ... public void setTotalEnergy(double E) { this.E = E; } public double getTotalEnergy() { return E; } ... The user of the framework will specify usage of this class in the Simulation.properties file in the following manner: PhysicalMeasurementClass=EnergyMeasurement
• CartesianObjectFactory: Factory class that implements PhysicalObjectFactory . Use this class to create object that are used in the study of Cartesian Coordinate Systems. To do this first indicate in the Simulation.properties the usage of the Factory and a corresponding PhysicalObject in the following manner: # Use the cartesian coordinate system. PhysicalObjectFactoryClass=feynman.framework.CartesianObjectFactory # User defined class of the PhysicalObject to use in the PhysicalSystem PhysicalObjectClass=CartesianParticle
• Marshaller: Utility class to load the properties file that the user has defined. If there is a switch to an XML format and using a real Marshalling/Unmarshalling tool like Castor, then this class can easily be refactored to an adaptor class. The constructor is private since this is a utility class so there is no instance of this class to create or get. To use this class treat it just like the Math utility class in the following manner: Simulation simulation = Marshaller.unmarshall("Simulation.properties");
• PhysicalSystemFactoryException: This excpetion is generally invoked when the user has either configured the properties file incorrectly by specifying a sub-class of the PhysicalObject that cannot be created by the Factory. An example would be if the user created a SphericalParticle that is a sub-class of SphericalObject which is a a sub-class of PhysicalObject . If the user tried to create the SphericalParticle with a CartesianObjectFactory, then this exception would be thrown.
• PhysicalObject: The class is really just a symbolic name that means more to physicists than the default Java Object class name means. It also helps to avoid confusion with the System class by establishing the semantic pattern in the framework of PhysicalObject and its counterpart PhysicalSystem. It does provide its sub-classes with an identifier mechanism and and equals method based on the unique identifier. This is useful for systems that contain many objects.
• PhysicalConfiguration: Interface for defining the configuration of a physical system before any operations or measurements are performed on the physical system. The class that will be used by the simulation should be defined in the Simulation.properties file in the following manner: # Define the class to use to configure the physical System. PhysicalConfigurationClass=InitialSetup
• Simulation: Bean that represents a simulation in the framework. Many of the attributes of the simulation bean are defined in the Simulation.properties file by the user of the framework. The Controller class uses the simulation bean to control the creation of the correct classes for the simulation.
• FinalReport: This interface defines a simple way of reporting final statistics or calculations that occured in the simulation. To define the usage of a FinalReport implement the following in the Simulation.properties file in the following manner: FinalReportClass=Report DoFinalReport=true
• PhysicalAlgorithm: This interface defines the mechanism for implementing a numerical algorithm for the simulation. The user of the framework will define an implementation and specify this in the Simulation.properties file in the following manner: PhysicalAlgorithmClass=SimpleGravity
• DataStore: Interface for defining data store capabilities within the framework for the PhysicalMeasurement bean. The data store could be as simple as a file or a database table. To check for the current supported implementations, check the documentation in the DataStoreFactory class.
• PhysicalObjectFactory: Factory to define the creation of Physical Objects to be used in the system of study. The sub-class will instantiate all objects that are used in the system. Example: CartesianObjectFactory creates CartesianParticle.
• PhysicalObjectFactoryException: This excpetion is generally invoked when the user has either configured the properties file incorrectly by specifying not specifying a sub-class of the PhysicalObject that cannot be created by the Factory.
• ControllerException: This excpetion is generally invoked when the user has either configured the properties file incorrectly or invoked the feynman.jar file with an incorrect command line.
• FileDataStore: File based implementation of the DataStore interface. This class makes use of the toString() method defined in the PhysicalMeasurement interface.
• DataStoreFactory: Factory class for the creation of particular DataStore implementation. The frameworkd currently supports the DataStoreFile implementation only.
• PhysicalSystem: A ObjectSystem is a collection of Objects that are being studied. This Interface describes the operations that can be performed on the system.
• MarshallingException: General exception that can occurr while marshalling and unmarshalling the simulation object.
• CartesianObject: Sub-class to define a PhysicalObject for the CartesianSystem .
• InvalidDataStoreException: Exception for when the user specifies and invalid data store type.
• ConnectionException: Generic Exception to catch dbms connection or file IO exceptions.
• PhysicalSystemFactory: Factory to create differenct types of PhysicalSystems .
• CartesianSystem: Class that creates a system of CartesianObjects .
• DbmsDataStore

Home | Contact Us | Privacy Policy | Terms of Service