Workspace/Siman-WS/WebContent/conf/som.xml

   1 <?xml version="1.0" encoding="UTF-8"?>
   2
   3 <project-structure>
   4
   5
   6 <!-- 1. Database physical location
   7      -->
   8     <database>
   9         <repository disk="W:/Eclipse workspace/SIMAN/Repository" />
  10     </database>
  11
  12
  13 <!-- 2. Formats
  14      -->
  15     <formats>
  16
  17 <!-- 2.1 Project elements identification scheme
  18      Studies, Knowledges and Documents are identified by unique user references. The structure of these references is customizable.
  19      You customize references through patterns.
  20      A reference's pattern is a character string including format directives. These format directives allow you to insert
  21      some information into the reference. The following directives are available:
  22      - %yy or %yyyy for inserting the entity creation year on 2 or 4 digits
  23      - %0000 for inserting a unique index, the number of digits being defined by the number of 0
  24      The above index is unique in the scope of cycle defined by the first format directive (year). In other words, this index
  25      restarts every new year. As such, for making references unique on this application server, both format directives (cycle
  26      and index) must be present in the pattern.
  27      Other characters are simply inserted as is in generated references. They can be used for extending the reference uniqueness
  28      beyond application servers, by adding a prefix specific to a given server (for example, a company department name).
  29      Given that these references may be used as directory or file names of the repository vault, the pattern must not include
  30      illicit characters such as '/', '?', '<' etc.
  31      -->
  32         <references  study="DER%yy%0000"/>
  33
  34 <!-- 2.2 Physical files naming scheme
  35      The physical data files stored into the repository vault can be named as follows:
  36      - By the user-defined title of corresponding documents ("title" name attribute below)
  37      - Encoded by a built-in scheme ("encoded" name attribute)
  38      - As is, that is, by keeping the name of the imported file ("asis" name attribute - not yet supported)
  39      Remarks:
  40      - When using the title scheme, as file names may include accent characters, client browsers must be configured for
  41        NOT encoding URLs as UTF-8.
  42      - Whatever is the naming scheme used, in order to avoid name clashes, file names are anyway suffixed by an index
  43        unique in the scope of the owner study.
  44      -->
  45         <files name="encoded"/>
  46
  47 <!-- 2.3 Document versions format
  48      -->
  49         <versions pattern="%M.%m[-%s]"/>
  50     </formats>
  51
  52
  53 <!-- 3. Document types
  54
  55      Warning: Articles must be ordered in a way that used document types (uses attribute values) must previously be defined.
  56      Example: "requirements" type must be defined before "specification" because "specification" uses "requirements".
  57      Remarks:
  58      - "knowledge" is a reserved word qualifying Knowledge Elements. So, it must not be used as a document type name.
  59      - "default" and "built-in" are also reserved words used for defining validation cycles.
  60      - In this version, the "uses" attribute is limited to 1 document type only.
  61      -->
  62     <documents>
  63         <article type="requirements"/>
  64         <article type="specification" uses="requirements"/>
  65         <article type="design"        uses="specification"/>
  66         <article type="geometry"      uses="design"/>
  67         <article type="model"         uses="geometry"/>
  68         <article type="loads"         uses="model"/>
  69         <article type="script"        uses="loads"/>
  70         <article type="log"           uses="script"/>
  71         <article type="results"       uses="script"/>
  72         <article type="report"        uses="results"/>
  73         <article type="memorandum"/>
  74         <article type="minutes"/>
  75     </documents>
  76
  77
  78 <!-- 4. Simulation Context types
  79
  80      Warning: The Simulation Context type "product" is mandatory as it is used by at least one application.
  81      -->
  82     <contexts>
  83
  84     <!-- General information -->
  85         <article type="customer"/>
  86         <article type="product"/>
  87         <article type="phase"/>            <!-- Phase of the product                                 -->
  88         <article type="need"/>             <!-- Customer needs                                       -->
  89         <article type="purpose"/>          <!-- Objective of the study                               -->
  90         <article type="physic"/>           <!-- Structure analysis, Thermal-hydraulics, Neutronic... -->
  91
  92     <!-- Geometry characteristics               Examples:                 -->
  93         <article type="object"/>           <!-- Car, Plane, Equipment...  -->
  94         <article type="part"/>             <!-- Crankcase, Outer layer... -->
  95         <artivle type="geometry"/>         <!-- Surface, Volume           -->
  96
  97     <!-- Model characteristics                  Examples:            -->
  98         <article type="model"/>            <!-- CSG, FEM...          -->
  99         <article type="element"/>          <!-- Bar, Surface, Volume -->
 100         <article type="shape"/>            <!-- (Surface) Triangle, Quadrangle... (Volume) Tetrahedron, Hexahedron... -->
 101         <article type="order"/>            <!-- First-order, Second-order... -->
 102
 103     <!-- Analysis type                          Examples:          -->
 104         <article type="analysis"/>         <!-- Static, Dynamic... -->
 105
 106     <!-- Software tools used -->
 107         <article type="platform"/>
 108         <article type="module"/>
 109         <article type="component"/>
 110     </contexts>
 111
 112
 113 <!-- 5. Knowledge Elements types
 114
 115      Warning: The Knowledge Elements type "usecase" is reserved for internal use.
 116      -->
 117     <knowledges>
 118         <article type="bestpractice"/>
 119         <article type="limitation"/>
 120         <article type="inconsistency"/>
 121         <article type="metrics"/>
 122         <article type="improvement"/>
 123     </knowledges>
 124
 125
 126 <!-- 6. User activities
 127
 128      Remarks:
 129      - Step names must naturally be unique.
 130      - Simulation Contexts must be attached to one classification step only.
 131      - Result document types must be results of one step only and be part of contents of the corresponding step.
 132      -->
 133     <activities>
 134         <step name="specification">
 135             <classification context="customer,product,phase,need,purpose,physic"/>
 136             <flow contents="requirements,specification,minutes" result="specification"/>
 137             <storage path="1.Study"/>
 138         </step>
 139       <scenario>
 140         <step name="design">
 141             <flow contents="design,memorandum,minutes" result="design"/>
 142             <storage path="1.Study"/>
 143         </step>
 144         <step name="modeling">
 145             <classification context="object,part,geometry"/>
 146             <flow contents="geometry,memorandum,minutes" result="geometry"/>
 147             <storage path="2.Geometry"/>
 148             <module name="GEOM"/>
 149             </step>
 150         <step name="meshing">
 151             <classification context="model,element,shape,order"/>
 152             <flow contents="model,memorandum,minutes" result="model"/>
 153             <storage path="3.Mesh"/>
 154             <module name="SMESH"/>
 155         </step>
 156         <step name="solving">
 157             <classification context="loads,script,platform,module,component"/>
 158             <flow contents="log,results,minutes" result="results"/>
 159             <storage path="5.Result"/>
 160             <module name="CASTEM"/>
 161         </step>
 162         <step name="postprocessing">
 163             <flow contents="memorandum,minutes"/>
 164             <storage path="6.Report"/>
 165         </step>
 166         <step name="capitalization">
 167             <flow contents="knowledge"/>
 168             <storage path="6.Report"/>
 169         </step>
 170       </scenario>
 171         <step name="reporting">
 172             <flow contents="report,minutes" result="report"/>
 173             <storage path="1.Study"/>
 174         </step>
 175     </activities>
 176
 177
 178 <!-- 6. Document validation cycles
 179      Validation cycles define the actors involved in the validation steps of documents. These steps can be
 180      "review", "approval" and "acceptance".
 181      Remarks:
 182      - Each validation cycle is defined by a tag corresponding to the type of an activity result document.
 183      - The actors of validation steps can be
 184        "manager", referring the responsible of study,
 185        "Nx1", referring the manager of the department (see User definition for more information),
 186        "Nx2", referring the boss of the department manager,
 187        "customer" (most likely involved in the acceptance step).
 188      -->
 189     <validations>
 190         <specification  review="Nx1"  approval="Nx2"/>
 191         <report         review="Nx1"  approval="Nx2"/>
 192         <default        review="manager"            />
 193     </validations>
 194
 195 <!-- 3. Check-in check-out information
 196      Defines the way documents involved in the check-in check-out operations must be processed.
 197      -->
 198     <mappings>
 199         <document type="geometry">
 200             <source format="step" process="file-download"/>   <!-- Geometry created from STEP import        -->
 201             <source format="py"   process="file-download"/>   <!-- Geometry created from Python execution   -->
 202             <source format="xml"  process="ocaf-import"/>     <!-- Geometry created interactively           -->
 203             <export format="brep"/>                           <!-- Result Shape                             -->
 204         </document>
 205         <document type="model">
 206             <source format="py"   process="file-download"/>   <!-- Mesh created from Python execution       -->
 207             <source format="xml"  process="ocaf-import"/>     <!-- Mesh including input parameters          -->
 208             <export format="med"/>                            <!-- Result mesh without input parameters     -->
 209         </document>
 210         <document type="loads">
 211             <source format="py"   process="file-download"/>   <!-- Input data created from Python execution -->
 212             <source format="c3m"  process="c3m-import"/>      <!-- Input data created interactively         -->
 213         </document>
 214         <document type="results">
 215             <source format="med"  process="med-import"/>      <!-- Calculation results source file          -->
 216         </document>
 217     </mappings>
 218 </project-structure>