+++ /dev/null
-<?xml version="1.0" encoding="UTF-8"?>
-
-<project-structure>
-
-
-<!-- 1. Database physical location
- The database includes an SQL base containing the studies and the document metadata, a Lucene index used for searching studies and
- knowledges, a file vault including all actual data and a directory where files uploaded and downloaded by users are temporarily saved.
- All these information are located in sub-directories of a common root directory defined below.
- This directory must be visible from the server application (Tomcat).
- -->
- <database>
- <repository disk="D:/users/rkv/SALOME_SIMER/rep" />
- </database>
-
-
-<!-- 2. Formats
- -->
- <formats>
-
-<!-- 2.1 Project elements identification scheme
- Studies, Knowledges and Documents are identified by unique user references. The structure of these references is customizable.
- You customize references through patterns.
- A reference's pattern is a character string including format directives. These format directives allow you to insert
- some information into the reference. The following directives are available:
- - %yy or %yyyy for inserting the entity creation year on 2 or 4 digits
- - %0000 for inserting a unique index, the number of digits being defined by the number of 0
- The above index is unique in the scope of cycle defined by the first format directive (year). In other words, this index
- restarts every new year. As such, for making references unique on this application server, both format directives (cycle
- and index) must be present in the pattern.
- Other characters are simply inserted as is in generated references. They can be used for extending the reference uniqueness
- beyond application servers, by adding a prefix specific to a given server (for example, a company department name).
- Given that these references may be used as directory or file names of the repository vault, the pattern must not include
- illicit characters such as '/', '?', '<', '>' etc.
- -->
- <references study="DER%yy%0000"/>
-
-<!-- 2.2 Physical files naming scheme
- The physical data files stored into the repository vault can be named as follows:
- - By the user-defined title of corresponding documents ("title" name attribute below)
- - Encoded by a built-in scheme ("encoded" name attribute)
- - As is, that is, by keeping the name of the imported file ("asis" name attribute - not yet supported)
- Remarks:
- - When using the title scheme, as file names may include accent characters, client browsers must be configured for
- NOT encoding URLs as UTF-8.
- - Whatever is the naming scheme used, in order to avoid name clashes, file names are anyway suffixed by an index
- unique in the scope of the owner study.
- -->
- <files name="encoded"/>
-
-<!-- 2.3 Document versions format
- Defines the format in which version numbers are presented to users.
- A version number includes a major, a minor and a branch number, when exist.
- -->
- <versions pattern="%M.%m[-%s]"/>
- </formats>
-
-
-<!-- 3. Study step types
- The user activities involved in studies are defined by study step types. The tag below simply lists all possible steps
- applicable in a workflow.
- Step types are defined by type names used in the API for accessing to study activities.
- The document data produced during these activities are saved into the repository vault. They can be structured in
- sub-directories of each study root directory. As such, the definition of study step types includes the path of the
- corresponding sub-directory.
- The list below does not define the order of steps - this order is specified by the workflow. The steps are listed in
- an order defining the internal index of steps. These index are used for localizing the activity names and corresponding
- folder names.
-
- Remark:
- - "scenario" is a reserved type name.
- -->
- <steps>
- <article type="specification" path="1.Study"/>
- <article type="design" path="1.Study"/>
- <article type="modeling" path="2.Geometry"/>
- <article type="meshing" path="3.Mesh"/>
- <article type="preprocessing" path="4.Load"/>
- <article type="solving" path="5.Result"/>
- <article type="postprocessing" path="6.Analysis"/>
- <article type="capitalization" path="7.Knowledge"/>
- <article type="reporting" path="1.Study"/>
- </steps>
-
-
-<!-- 4. Document types
- All documents under the control of the Study Manager are typed. The tag below simply lists all possible document types
- involved in a workflow.
- Document types are defined by type names used in the API for manipulating document types. These type names are also used
- for localizing document types.
- The documents have dependencies in accordance to their type. As such, the definition of each document type include the
- potential dependencies of corresponding documents.
-
- Warning: Articles must be ordered in a way that dependent document types (uses attribute values) must previously be defined.
- Example: "requirements" type must be defined before "specification" because "specification" uses "requirements".
- Remarks:
- - The dependencies are transitive (if document A depends on document B, itself depending on C, A implicitly depends on C).
- - "knowledge" is a reserved word qualifying Knowledge Elements. So, it must not be used as a document type name.
- - "default" and "built-in" are also reserved words used for defining validation cycles.
- - In this version, the "uses" attribute is limited to 1 document type only.
- -->
- <documents>
- <article type="requirements"/>
- <article type="specification" uses="requirements"/>
- <article type="design" uses="specification"/>
- <article type="geometry" uses="design"/>
- <article type="model" uses="geometry"/>
- <article type="loads" uses="model"/>
- <article type="script" uses="loads"/>
- <article type="log" uses="script"/>
- <article type="results" uses="script"/>
- <article type="report" uses="results"/>
- <article type="memorandum"/>
- <article type="minutes"/>
- </documents>
-
-
-<!-- 5. Simulation Context types
- As documents, the simulation contexts are typed. The tag below simply lists the simulation context types available initially,
- after the installation of the product. These types can then be extended on the fly by end-users when assigning simulation
- contexts to studies.
- Simulation context types are defined by type names used in the API for manipulating simulation contexts. These type names
- are also used for localizing simulation contexts types.
-
- Warning: The Simulation Context type "product" is mandatory as it is used when creating a study.
- -->
- <contexts>
-
- <!-- General information -->
- <article type="customer"/>
- <article type="product"/>
- <article type="phase"/> <!-- Phase of the product -->
- <article type="need"/> <!-- Customer needs -->
- <article type="purpose"/> <!-- Objective of the study -->
- <article type="physic"/> <!-- Structure analysis, Thermal-hydraulics, Neutronic... -->
-
- <!-- Geometry characteristics Examples: -->
- <article type="object"/> <!-- Car, Plane, Equipment... -->
- <article type="part"/> <!-- Crankcase, Outer layer... -->
- <artivle type="geometry"/> <!-- Surface, Volume -->
-
- <!-- Model characteristics Examples: -->
- <article type="model"/> <!-- CSG, FEM... -->
- <article type="element"/> <!-- Bar, Surface, Volume -->
- <article type="shape"/> <!-- (Surface) Triangle, Quadrangle... (Volume) Tetrahedron, Hexahedron... -->
- <article type="order"/> <!-- First-order, Second-order... -->
-
- <!-- Analysis type Examples: -->
- <article type="analysis"/> <!-- Static, Dynamic... -->
-
- <!-- Software tools used -->
- <article type="platform"/>
- <article type="module"/>
- <article type="component"/>
- </contexts>
-
-
-<!-- 6. Knowledge Elements types
- As documents and simulation contexts, the knowledges are typed. The tag below lists these knowledge types.
- Knowledge types are simply defined by type names used in the API for manipulating knowledge types. These type names
- are also used for localizing knowledge types.
-
- Warning: The Knowledge Elements type "usecase" is reserved for internal use.
- -->
- <knowledges>
- <article type="bestpractice"/>
- <article type="limitation"/>
- <article type="inconsistency"/>
- <article type="metrics"/>
- <article type="improvement"/>
- </knowledges>
-
-
-<!-- 7. User activities
-
- Remarks:
- - Step names must naturally be unique.
- - Simulation Contexts must be attached to one classification step only.
- - Result document types must be results of one step only and be part of contents of the corresponding step.
- -->
- <activities>
- <step name="specification">
- <classification context="customer,product,phase,need,purpose,physic"/>
- <flow contents="requirements,specification,minutes" result="specification"/>
- <storage path="1.Study"/>
- </step>
- <scenario>
- <step name="design">
- <flow contents="design,memorandum,minutes" result="design"/>
- <storage path="1.Study"/>
- </step>
- <step name="modeling">
- <classification context="object,part,geometry"/>
- <flow contents="geometry,memorandum,minutes" result="geometry"/>
- <storage path="2.Geometry"/>
- </step>
- <step name="meshing">
- <classification context="model,element,shape,order"/>
- <flow contents="model,memorandum,minutes" result="model"/>
- <storage path="3.Mesh"/>
- </step>
- <step name="preprocessing">
- <classification context="analysis"/>
- <flow contents="loads,script,minutes" result="loads"/>
- <storage path="4.Analysis"/>
- </step>
- <step name="solving">
- <classification context="platform,module,component"/>
- <flow contents="log,results,minutes" result="results"/>
- <storage path="5.Result"/>
- </step>
- <step name="postprocessing">
- <flow contents="memorandum,minutes"/>
- <storage path="6.Report"/>
- </step>
- <step name="capitalization">
- <flow contents="knowledge"/>
- <storage path="6.Report"/>
- </step>
- </scenario>
- <step name="reporting">
- <flow contents="report,minutes" result="report"/>
- <storage path="1.Study"/>
- </step>
- </activities>
-
-
-<!-- 8. Document validation cycles
- Validation cycles define the actors involved in the validation steps of documents. These steps can be
- "review", "approval" and "acceptance".
- Remarks:
- - Each validation cycle is defined by a tag corresponding to the type of an activity result document.
- - The actors of validation steps can be
- "manager", referring the responsible of study,
- "Nx1", referring the manager of the department (see User definition for more information),
- "Nx2", referring the boss of the department manager,
- "customer" (most likely involved in the acceptance step).
- -->
- <validations>
- <specification review="Nx1" approval="Nx2"/>
- <report review="Nx1" approval="Nx2"/>
- <default review="manager" />
- </validations>
-
-</project-structure>
\ No newline at end of file
