Show Posts
1
General Board / Re: What is an appropriate UML element for a data item?
« on: April 04, 2019, 02:42:21 pm »
Hi mse,
This could be way off the mark without really knowing your modeling context, but as it sounds like you're effectively linking requirements directly to a well defined domain model, you could be on the right track in creating a reference to one of your enumeration literals.
From what you wrote, it seems you've already got some kind of enumeration element like 'MyStatusKind'. It seems like that element's values are shared by both the monitored and controlled variables. I guess the enumeration has literals like ON, OFF, FAULT (or UNDEFINED) and perhaps others. So you could simply drag and drop the appropriate literal into your text in the linked document.
Regarding the Boolean idea, that could be neat if you really do have only two possible values and the true/false values really do map meaningfully to your status values. Regarding the latter condition, maybe you could safely assume that ON means true. But it would just be going on some kind of conventional understanding... if you want a rough analogy in which one set of binary values has a counterintuitive mapping, compare conditional logic in the C programming language to a Shell exit status. In C conditional logic, false maps intuitively to 0, whereas in Shell an exit status of 0 means success. There are good reasons for that of course and strictly speaking a Shell exit status isn't actually binary, which leads to the first condition I raised...
Do you really have only two possible status values? So many times, I thought I'd captured an information item with a simple Boolean data type, only to discover I have more than 'On' and 'Off' as status values for example. I find out there are 'uninitialized', 'read error' and the like. Maybe your system can make certain assumptions for the monitored variable in the case when there's actually no value read, so two values might work. But maybe the control variable can be in some error state or unset/uninitialized - so these are additional to your 'On' and 'Off' statuses - you'll have knowledge of those details though.
Anyway, it could be useful to stick with an enumeration literal so your model imparts more meaning, even if there are only two status values. In this case, I'd treat the Boolean type and even '0' and '1' as more of an implementation detail for a logical model, where your system might be able to use Boolean type for optimal storage instead of an enumeration or whatever other data structure. If you do end up actually using a Boolean attribute in your domain model (or data/information model) and you need to refer to either of its literal values, then you'd probably just link the text 'true' or 'false' to the Boolean-typed attribute. (So you'd type the text, select it, right-click and choose create - hyperlink - attribute.) There may be other good, or much better ways, of achieving what you're after though.
I hope that helps.
Ben
This could be way off the mark without really knowing your modeling context, but as it sounds like you're effectively linking requirements directly to a well defined domain model, you could be on the right track in creating a reference to one of your enumeration literals.
From what you wrote, it seems you've already got some kind of enumeration element like 'MyStatusKind'. It seems like that element's values are shared by both the monitored and controlled variables. I guess the enumeration has literals like ON, OFF, FAULT (or UNDEFINED) and perhaps others. So you could simply drag and drop the appropriate literal into your text in the linked document.
Regarding the Boolean idea, that could be neat if you really do have only two possible values and the true/false values really do map meaningfully to your status values. Regarding the latter condition, maybe you could safely assume that ON means true. But it would just be going on some kind of conventional understanding... if you want a rough analogy in which one set of binary values has a counterintuitive mapping, compare conditional logic in the C programming language to a Shell exit status. In C conditional logic, false maps intuitively to 0, whereas in Shell an exit status of 0 means success. There are good reasons for that of course and strictly speaking a Shell exit status isn't actually binary, which leads to the first condition I raised...
Do you really have only two possible status values? So many times, I thought I'd captured an information item with a simple Boolean data type, only to discover I have more than 'On' and 'Off' as status values for example. I find out there are 'uninitialized', 'read error' and the like. Maybe your system can make certain assumptions for the monitored variable in the case when there's actually no value read, so two values might work. But maybe the control variable can be in some error state or unset/uninitialized - so these are additional to your 'On' and 'Off' statuses - you'll have knowledge of those details though.
Anyway, it could be useful to stick with an enumeration literal so your model imparts more meaning, even if there are only two status values. In this case, I'd treat the Boolean type and even '0' and '1' as more of an implementation detail for a logical model, where your system might be able to use Boolean type for optimal storage instead of an enumeration or whatever other data structure. If you do end up actually using a Boolean attribute in your domain model (or data/information model) and you need to refer to either of its literal values, then you'd probably just link the text 'true' or 'false' to the Boolean-typed attribute. (So you'd type the text, select it, right-click and choose create - hyperlink - attribute.) There may be other good, or much better ways, of achieving what you're after though.
I hope that helps.
Ben
. For others starting out with generating tabular reports in EA - say for a data dictionary and the like - this 2-part webinar shows how to do it with a complete worked example:
