cellml · codecurve · Aug 24, 2014 · Aug 24, 2014 · Aug 25, 2014 · Aug 25, 2014
diff --git a/.project b/.project
@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<projectDescription>
+	<name>libCellML01</name>
+	<comment></comment>
+	<projects>
+	</projects>
+	<buildSpec>
+	</buildSpec>
+	<natures>
+	</natures>
+</projectDescription>
diff --git a/docs/source/conf.py b/docs/source/conf.py
@@ -48,7 +48,7 @@
 
 # General information about the project.
 project = u'libCellML'
-copyright = u'2014, David Nickerson'
+copyright = u'2014, David Nickerson, Randall Britten'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
@@ -201,7 +201,7 @@
 #  author, documentclass [howto, manual, or own class]).
 latex_documents = [
   ('index', 'libCellML.tex', u'libCellML Documentation',
-   u'David Nickerson', 'manual'),
+   u'David Nickerson, Randall Britten', 'manual'),
 ]
 
 # The name of an image file (relative to this directory) to place at the top of
@@ -231,7 +231,7 @@
 # (source start file, name, description, authors, manual section).
 man_pages = [
     ('index', 'libcellml', u'libCellML Documentation',
-     [u'David Nickerson'], 1)
+     [u'David Nickerson, Randall Britten'], 1)
 ]
 
 # If true, show URL addresses after external links.
@@ -245,7 +245,7 @@
 #  dir menu entry, description, category)
 texinfo_documents = [
   ('index', 'libCellML', u'libCellML Documentation',
-   u'David Nickerson', 'libCellML', 'One line description of project.',
+   u'David Nickerson, Randall Britten', 'libCellML', 'One line description of project.',
    'Miscellaneous'),
 ]
 

diff --git a/docs/source/imageExports/Encapsulation.PNG b/docs/source/imageExports/Encapsulation.PNG
diff --git a/docs/source/imageExports/Imports.PNG b/docs/source/imageExports/Imports.PNG
diff --git a/docs/source/imageExports/Model_Class.PNG b/docs/source/imageExports/Model_Class.PNG
diff --git a/docs/source/imageExports/Units_of_measure.PNG b/docs/source/imageExports/Units_of_measure.PNG
diff --git a/docs/source/imageExports/Variable.PNG b/docs/source/imageExports/Variable.PNG
diff --git a/docs/source/imageExports/libCellML_01_01.PNG b/docs/source/imageExports/libCellML_01_01.PNG
diff --git a/docs/source/index.rst b/docs/source/index.rst
@@ -13,9 +13,10 @@ Contents:
    :maxdepth: 2
    :titlesonly:
 
+   projectIntro
    roadmap
-
-
+   objectModel
+   
 
 Indices and tables
 ==================

diff --git a/docs/source/objectModel.rst b/docs/source/objectModel.rst
@@ -0,0 +1,83 @@
+.. _libcellmlObjectModel:
+
+libCellML Object Model
+=================
+
+Randall Britten, 26 August 2014
+
+
+Introduction
+------------
+The object model is (currently) a very high level conceptual design. The focus has been on a design to support the initial use case from the roadmap (i.e. Create model, save as XML.  An "isValid" method does not yet exist in the design, since the "validate" use case follows later).
+
+
+Preamble
+--------
+UML images are created using Eclipse/Papyrus. Some detail may not show in the diagrams, or be explained in this text, so if you are in doubt, please refer to the model details in Eclipse/Papyrus.
+Collections are often indicated as an association from one class to another (or the same class if the containment is recursive) on a class diagram.  At this stage, methods for adding and removing from the collection are omitted from the diagram.
+Often, some of the member operations and properties of a class are hidden on some of the diagrams on which it appears.  Also, a class may be shown multiple times on the same diagram.
+
+Remember to pay attention to the arrows indicating navigability of associations, as well as the cardinality of the association ends.
+
+It was realised recently that some cases where UML classes have been specified should perhaps be interfaces.
+
+
+Overview of object model
+------------------------
+.. figure:: imageExports/libCellML_01_01.PNG
+
+Shown in this overview:
+
+#.  A model has a collection of components and a collection of units.
+#.  A component has a collection of variables, and a collection of "Maths" objects.  This design does not yet have any details for how maths is represented, it will probably be the abstract syntax tree (AST) of the MathML.
+#.  A component also has a collection of the units defined within the component.
+
+Model class
+-----------
+.. figure:: imageExports/Model_Class.PNG
+
+#. getXML returns the XML serialisation for the model as text (alternate representations should be considered, e.g. AST or DOM).
+#. addImport creates the Import object with just the URL provided as a string.
+
+
+Details for variable object model
+---------------------------------
+.. figure:: imageExports/Variable.PNG
+
+#.  Variables may be real or boolean.  (Real is taken to mean that the codomain is real.  Thus state variables are treated as real variables, even though they are actually real valued functions of the variable of integration (VOI). Constant real values fall into this category (i.e. real is isomorphic to () -> reals, where () is the nullary Cartesian product).
+#. Only real variables have units.
+#. Variables have a collection (which may be empty) of the variables to which they are connected. Note that this is not normalised at this conceptual level, (i.e. From A you can see B in the list of connected variables, and from B you can see A in the set of connected variables.  Nevertheless, the implementation is likely to be normalised, and the XML representation likewise will have a normalised representation, where a connection element indicates that A is connected to B.
+
+Encapsulation
+-------------
+.. figure:: imageExports/Encapsulation.PNG
+
+#. A component object has a collection of components that are encapsulated by it.  This is recursive.  Note: the design allows for cycles, but the spec does not.
+
+Units of measure
+----------------
+.. figure:: imageExports/Units_of_measure.PNG
+
+#. The base class has a property for the unit name, and a boolean flag to indicate whether the unit is built-in.
+#. Units may be either base units or derived units.  
+#. A derived unit has a collection of "UnitsReference" objects that represent the definition of the derived unit.
+
+Imports
+-------
+.. figure:: imageExports/Imports.PNG
+
+#. The component class has a subtype for imported components.  
+#. An imported component's local name is the stored by the inherited name attribute, the name of the component in the imported file is stored in the "remoteName" attribute.
+
+Stand-alone methods
+-------------------
+Methods not shown on UML yet, but would be useful.
+
+#. getBuiltinUnits() : [Unit] - returns a collection of the built-in units.
+
+Todo
+----
+#. Some documentation of classes, operations etc in this document probably belong as documentation in the Papyrus model, and eventually as the Doxygen comments on the C++ code, Python docs, Java docs etc.
+#. Details of math representation an utilities
+#. Details of XML representation and utilities
+#. Change classes to interfaces where appropriate
diff --git a/docs/source/projectIntro.rst b/docs/source/projectIntro.rst
@@ -0,0 +1,28 @@
+.. _projectIntro:
+
+Introducing the libCellML project
+=================================
+
+Randall Britten, 27 August 2014
+
+The libCellML project aims to provide a library for working with CellML, focussed on CellML 1.2, but with limited support for older formats (i.e. CellML 1.0 and 1.1). 
+
+The motivation for the libCellML project
+----------------------------------------
+
+A fresh start at creating core software support for tool developers that would like to make use of the CellML standard in their tools. LibCellML will be implemented in a manner that makes it easier and more natural to work with than the `previous CellML API project <http://cellml-api.sf.net>`_. Some further information is available in the :ref:`libcellmlRoadmap`.
+
+Status of CellML 1.2
+--------------------
+There is not yet a document that represents CellML 1.2 will differ from the previous version.  However, the following are good sources for indicating what CellML 1.2 might look like:
+
+#. Starting point `document <https://cellml-specification.readthedocs.org/en/latest/>`_ for editorial board working draft. This currently describes CellML 1.1 minus reactions.  The aim is to incrementally edit this with version history mapping to the relevant tracker items so that a good provenance record is available.
+#. `An e-mail <https://lists.cellml.org/sympa/arc/cellml-discussion/2012-10/msg00005.html>`_ reporting on the planning for CellML 1.2 at the 2012 CellML workshop
+#. `A rendering of one proposal <http://codecurve.github.io/cellml-core-spec/>`_ from previous work towards a draft of CellML 1.2 that was done before the editorial board process was in place.  Note however that this assumes the use of MathML 3.  In conjunction with this, there is this `draft of a secondary specification <http://codecurve.github.io/cellml-dae-events-secondary/>`_ which captures the types of models usually represented using previous versions of CellML. The editorial board plans to use some of the text from these drafts.
+
+
+Expected availability
+---------------------
+At this stage, it has been decided to undertake the libCellML project based on rough time estimates only, hence there is very little certainty yet as to when the first versions that are practically useful will be available.  The libCellML project will aim to deliver some functionality as early as possible.  An iterative development methodology will aim to provide updated versions with additional functionality regularly.  Again, please see :ref:`libcellmlRoadmap`.
+
+
diff --git a/model.di b/model.di
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"/>
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,2 @@
		<?xml version="1.0" encoding="UTF-8"?>
		<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"/>