Workspace/Siman/src/som.xml

   1 <?xml version="1.0" encoding="UTF-8"?>
   2
   3 <project-structure>
   4
   5
   6 <!-- 1. Database physical location
   7      The database includes an SQL base containing the studies and the document metadata, a Lucene index used for searching studies and
   8      knowledges, a file vault including all actual data and a directory where files uploaded and downloaded by users are temporarily saved.
   9      All these information are located in sub-directories of a common root directory defined below.
  10      This directory must be visible from the server application (Tomcat).
  11      -->
  12     <database>
  13         <repository disk="D:/users/rkv/SALOME_SIMER/rep" />
  14     </database>
  15
  16
  17 <!-- 2. Formats
  18      -->
  19     <formats>
  20
  21 <!-- 2.1 Project elements identification scheme
  22      Studies, Knowledges and Documents are identified by unique user references. The structure of these references is customizable.
  23      You customize references through patterns.
  24      A reference's pattern is a character string including format directives. These format directives allow you to insert
  25      some information into the reference. The following directives are available:
  26      - %yy or %yyyy for inserting the entity creation year on 2 or 4 digits
  27      - %0000 for inserting a unique index, the number of digits being defined by the number of 0
  28      The above index is unique in the scope of cycle defined by the first format directive (year). In other words, this index
  29      restarts every new year. As such, for making references unique on this application server, both format directives (cycle
  30      and index) must be present in the pattern.
  31      Other characters are simply inserted as is in generated references. They can be used for extending the reference uniqueness
  32      beyond application servers, by adding a prefix specific to a given server (for example, a company department name).
  33      Given that these references may be used as directory or file names of the repository vault, the pattern must not include
  34      illicit characters such as '/', '?', '<', '>' etc.
  35      -->
  36         <references  study="DER%yy%0000"/>
  37
  38 <!-- 2.2 Physical files naming scheme
  39      The physical data files stored into the repository vault can be named as follows:
  40      - By the user-defined title of corresponding documents ("title" name attribute below)
  41      - Encoded by a built-in scheme ("encoded" name attribute)
  42      - As is, that is, by keeping the name of the imported file ("asis" name attribute - not yet supported)
  43      Remarks:
  44      - When using the title scheme, as file names may include accent characters, client browsers must be configured for
  45        NOT encoding URLs as UTF-8.
  46      - Whatever is the naming scheme used, in order to avoid name clashes, file names are anyway suffixed by an index
  47        unique in the scope of the owner study.
  48      -->
  49         <files name="encoded"/>
  50
  51 <!-- 2.3 Document versions format
  52      Defines the format in which version numbers are presented to users.
  53      A version number includes a major, a minor and a branch number, when exist.
  54      -->
  55         <versions pattern="%M.%m[-%s]"/>
  56     </formats>
  57
  58
  59 <!-- 3. Study step types
  60      The user activities involved in studies are defined by study step types. The tag below simply lists all possible steps
  61      applicable in a workflow.
  62      Step types are defined by type names used in the API for accessing to study activities.
  63      The document data produced during these activities are saved into the repository vault. They can be structured in
  64      sub-directories of each study root directory. As such, the definition of study step types includes the path of the
  65      corresponding sub-directory.
  66      The list below does not define the order of steps - this order is specified by the workflow. The steps are listed in
  67      an order defining the internal index of steps. These index are used for localizing the activity names and corresponding
  68      folder names.
  69
  70      Remark:
  71      - "scenario" is a reserved type name.
  72      -->
  73     <steps>
  74         <article type="specification"  path="1.Study"/>
  75         <article type="design"         path="1.Study"/>
  76         <article type="modeling"       path="2.Geometry"/>
  77         <article type="meshing"        path="3.Mesh"/>
  78         <article type="preprocessing"  path="4.Load"/>
  79         <article type="solving"        path="5.Result"/>
  80         <article type="postprocessing" path="6.Analysis"/>
  81         <article type="capitalization" path="7.Knowledge"/>
  82         <article type="reporting"      path="1.Study"/>
  83     </steps>
  84
  85
  86 <!-- 4. Document types
  87      All documents under the control of the Study Manager are typed. The tag below simply lists all possible document types
  88      involved in a workflow.
  89      Document types are defined by type names used in the API for manipulating document types. These type names are also used
  90      for localizing document types.
  91      The documents have dependencies in accordance to their type. As such, the definition of each document type include the
  92      potential dependencies of corresponding documents.
  93
  94      Warning: Articles must be ordered in a way that dependent document types (uses attribute values) must previously be defined.
  95      Example: "requirements" type must be defined before "specification" because "specification" uses "requirements".
  96      Remarks:
  97      - The dependencies are transitive (if document A depends on document B, itself depending on C, A implicitly depends on C).
  98      - "knowledge" is a reserved word qualifying Knowledge Elements. So, it must not be used as a document type name.
  99      - "default" and "built-in" are also reserved words used for defining validation cycles.
 100      - In this version, the "uses" attribute is limited to 1 document type only.
 101      -->
 102     <documents>
 103         <article type="requirements"/>
 104         <article type="specification" uses="requirements"/>
 105         <article type="design"        uses="specification"/>
 106         <article type="geometry"      uses="design"/>
 107         <article type="model"         uses="geometry"/>
 108         <article type="loads"         uses="model"/>
 109         <article type="script"        uses="loads"/>
 110         <article type="log"           uses="script"/>
 111         <article type="results"       uses="script"/>
 112         <article type="report"        uses="results"/>
 113         <article type="memorandum"/>
 114         <article type="minutes"/>
 115     </documents>
 116
 117
 118 <!-- 5. Simulation Context types
 119      As documents, the simulation contexts are typed. The tag below simply lists the simulation context types available initially,
 120      after the installation of the product. These types can then be extended on the fly by end-users when assigning simulation
 121      contexts to studies.
 122      Simulation context types are defined by type names used in the API for manipulating simulation contexts. These type names
 123      are also used for localizing simulation contexts types.
 124
 125      Warning: The Simulation Context type "product" is mandatory as it is used when creating a study.
 126      -->
 127     <contexts>
 128
 129     <!-- General information -->
 130         <article type="customer"/>
 131         <article type="product"/>
 132         <article type="phase"/>            <!-- Phase of the product                                 -->
 133         <article type="need"/>             <!-- Customer needs                                       -->
 134         <article type="purpose"/>          <!-- Objective of the study                               -->
 135         <article type="physic"/>           <!-- Structure analysis, Thermal-hydraulics, Neutronic... -->
 136
 137     <!-- Geometry characteristics               Examples:                 -->
 138         <article type="object"/>           <!-- Car, Plane, Equipment...  -->
 139         <article type="part"/>             <!-- Crankcase, Outer layer... -->
 140         <artivle type="geometry"/>         <!-- Surface, Volume           -->
 141
 142     <!-- Model characteristics                  Examples:            -->
 143         <article type="model"/>            <!-- CSG, FEM...          -->
 144         <article type="element"/>          <!-- Bar, Surface, Volume -->
 145         <article type="shape"/>            <!-- (Surface) Triangle, Quadrangle... (Volume) Tetrahedron, Hexahedron... -->
 146         <article type="order"/>            <!-- First-order, Second-order... -->
 147
 148     <!-- Analysis type                          Examples:          -->
 149         <article type="analysis"/>         <!-- Static, Dynamic... -->
 150
 151     <!-- Software tools used -->
 152         <article type="platform"/>
 153         <article type="module"/>
 154         <article type="component"/>
 155     </contexts>
 156
 157
 158 <!-- 6. Knowledge Elements types
 159      As documents and simulation contexts, the knowledges are typed. The tag below lists these knowledge types.
 160      Knowledge types are simply defined by type names used in the API for manipulating knowledge types. These type names
 161      are also used for localizing knowledge types.
 162
 163      Warning: The Knowledge Elements type "usecase" is reserved for internal use.
 164      -->
 165     <knowledges>
 166         <article type="bestpractice"/>
 167         <article type="limitation"/>
 168         <article type="inconsistency"/>
 169         <article type="metrics"/>
 170         <article type="improvement"/>
 171     </knowledges>
 172
 173
 174 <!-- 7. User activities
 175
 176      Remarks:
 177      - Step names must naturally be unique.
 178      - Simulation Contexts must be attached to one classification step only.
 179      - Result document types must be results of one step only and be part of contents of the corresponding step.
 180      -->
 181     <activities>
 182         <step name="specification">
 183             <classification context="customer,product,phase,need,purpose,physic"/>
 184             <flow contents="requirements,specification,minutes" result="specification"/>
 185             <storage path="1.Study"/>
 186         </step>
 187       <scenario>
 188         <step name="design">
 189             <flow contents="design,memorandum,minutes" result="design"/>
 190             <storage path="1.Study"/>
 191         </step>
 192         <step name="modeling">
 193             <classification context="object,part,geometry"/>
 194             <flow contents="geometry,memorandum,minutes" result="geometry"/>
 195             <storage path="2.Geometry"/>
 196             </step>
 197         <step name="meshing">
 198             <classification context="model,element,shape,order"/>
 199             <flow contents="model,memorandum,minutes" result="model"/>
 200             <storage path="3.Mesh"/>
 201         </step>
 202         <step name="preprocessing">
 203             <classification context="analysis"/>
 204             <flow contents="loads,script,minutes" result="loads"/>
 205             <storage path="4.Analysis"/>
 206         </step>
 207         <step name="solving">
 208             <classification context="platform,module,component"/>
 209             <flow contents="log,results,minutes" result="results"/>
 210             <storage path="5.Result"/>
 211         </step>
 212         <step name="postprocessing">
 213             <flow contents="memorandum,minutes"/>
 214             <storage path="6.Report"/>
 215         </step>
 216         <step name="capitalization">
 217             <flow contents="knowledge"/>
 218             <storage path="6.Report"/>
 219         </step>
 220       </scenario>
 221         <step name="reporting">
 222             <flow contents="report,minutes" result="report"/>
 223             <storage path="1.Study"/>
 224         </step>
 225     </activities>
 226
 227
 228 <!-- 8. Document validation cycles
 229      Validation cycles define the actors involved in the validation steps of documents. These steps can be
 230      "review", "approval" and "acceptance".
 231      Remarks:
 232      - Each validation cycle is defined by a tag corresponding to the type of an activity result document.
 233      - The actors of validation steps can be
 234        "manager", referring the responsible of study,
 235        "Nx1", referring the manager of the department (see User definition for more information),
 236        "Nx2", referring the boss of the department manager,
 237        "customer" (most likely involved in the acceptance step).
 238      -->
 239     <validations>
 240         <specification  review="Nx1"  approval="Nx2"/>
 241         <report         review="Nx1"  approval="Nx2"/>
 242         <default        review="manager"            />
 243     </validations>
 244
 245 </project-structure>