Difference between revisions of "Notice time"
Jump to navigation
Jump to search
m |
|||
| Line 18: | Line 18: | ||
Remark: Product specifications which allow multiplicity > 1 for this attribute should state whether the order of values has any significance and explain the significance. | Remark: Product specifications which allow multiplicity > 1 for this attribute should state whether the order of values has any significance and explain the significance. | ||
| + | |||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | Jens (BSH); I agree with that proposal. Looks pretty much better than our initial ideal of notice time (refer to the attribute section) | ||
Revision as of 17:41, 30 October 2009
Notice time can become a complex attribute using the operation idea Raphael proposed and which is been used at Under Keel clearance. The construction can be like to following
| Sub-attribute | Camel Code Identifier | multiplicity | sequential |
|---|---|---|---|
| NTCHRS | noticeTimeHours | 0..* | 1 |
| NTCTXT | noticeTimeText | 0..1 | n/a |
| OPERAT | operation | 0..1 | n/a |
That enabled us to model constructions like:
Notice is required 48, 24, 6 hrs in advance or when leaving the previous port whichever is less.
A further instance can be: Confirmation 2 hrs before arriving the xx-position.
Remark: Product specifications which allow multiplicity > 1 for this attribute should state whether the order of values has any significance and explain the significance.
Jens (BSH); I agree with that proposal. Looks pretty much better than our initial ideal of notice time (refer to the attribute section)