Sheet: 'ISM General Classes'
- Last UpdatedJun 20, 2024
- 3 minute read
This sheet defines General Classes and Sub Classes. Classes that do not fall into one of the categories Functional, Physical or Document. For example, System, Area and Contractor.
An abstract class, "Root General Class" (@id="ISM_ROOT_GENERAL"), will be created automatically as the root of the class hierarchy, with all top level classes (classes with no "Extends") extending this class. You are free to define properties for this root class, by including a class definition with Id=" ISM_ROOT_ GENERAL" in this sheet.
|
Item |
Column Name |
Constraint |
Description |
|---|---|---|---|
|
1 |
Id |
Required |
|
|
2 |
Name |
A human readable name for the Class definition. |
|
|
3 |
Name {language} |
|
|
|
4 |
Description |
An arbitrary description for the purpose/role of the Class. |
|
|
5 |
Description {language} |
|
|
|
6 |
Abstract |
|
|
|
7 |
Discipline |
|
|
|
8 |
NamingTemplate_Id |
|
|
|
9 |
NamingTemplate_ ApplicableFor |
|
|
|
10 |
LifeCycleType |
A reference to the identifier of a Life Cycle Type that is applicable for the Class. |
|
|
11 |
Extends |
|
|
|
12 |
Aspect |
Annotating a Class with an aspect is a way to associate the Class with a specific semantic definition. Application logic will look for these aspects, and apply associated processing rules. Definition of available aspect values is outside the scope of this document. |
|
|
13 |
Obsolete |
|
When evolving a Class Library over time, removing previously existing definitions might cause issues with consuming software systems (for example, they might not support deleting a class that is in use for existing data). Obsoleting deprecated definitions might therefore be a less intrusive approach. How, or whether, obsoleting is implemented might vary across consuming software though. |
|
14 |
SortOrder |
- A signed integer value |
|