How to model attribute dependency “inside one class” in class diagram?

[Shegit Brahm]

Hi there,

I have the following "software reality in working code" (also no access to it):

    There is a class Class1 with different attributes
        AttributeA - sums up all "ordinary attributes"
        EnumType
        DataType
        AttributeValue

It is realized that there are some objects John... of type Class1, so they all have these 4 attributes. They can be set via GUI. The tricky part is: First EnumType has to be chosen. Depending on this choice the possible choices for DataType might be reduced. And the "attribute type" of AttributeValue might differ:

    EnumType = None => DataType: int | char && AttributeValue: Field
    EnumType = List => DataType: int | char | double | String && Value: []-Array
    EnumType = Diction => DataType: int | char | double | String | XML && Value: DictCollection

That means:
If "None" than Value is only a single "field" of some possible data types.
If "List" than Value is like an []-Array where there is a long list of storable entries, it is gui chosen which data type this instantiation gets (and than all entries have same), possible data types are a bit more than "None".
If "Diction" than Value is like a collection of attribute pairs, it is gui chosen which data type this instantiation gets (and than each pair has the same combination), possible data types are more than "List".

Example:
JohnA: None=>Field | => char ='a' | AttributeA
JohnB: None=>Field | => int = 23 | AttributeA
JohnC: List=>[]Array | => String =["hello","world","list"] | AttributeA
JohnD: Diction=>DictCollection | => {XML, double} = {(<length>, 2.34); (<width>, 5.43)} | AttributeA



How to model Class1 in UML class diagram?

Additional info: this Class1 also needs to be used in another class as data type of attributes over there as well - just in case that is relevant to ensure that while using it as data type the class structure and inner dependencies are coming into affect.

I read a bit and got some hints, I just don't understand them fully:
- when (not) to use a "refine"?
- when (not) to use a "derive"?

I understood, that a "refine" is useful in specialization where the subclass attribute has same name and different data type.
I understood, that  a "derive" is useful in case an attribute depends on e.g. values of another like it gets calculated (calc "age" from "birthday" and "today").
I understood that a "readonly" is useful e.g. in a specialization in combination with a default value when this default is the only one possible for this subclass. (despite "query" which just describes that the attribute has no changing effect to this class).

The hints are summarized in this approach:


As you might see,

• the Class1 became abstract
• there are three specializations for each EnumType
• ClassDiction has no "redefines Value" (due to my lack of understanding)
• DictCollection is shown as separate class as pair of key, counterkey
• the enums for data types got specializations the way down

I have the feeling that "Value" needs two attributes: one aspect is: it defines the structure, second aspect is: it defines the data type inside the structure.
Or is this stored in "DataType" because this attribute is there to determine the data type of "Value" - and then it needs somehow an information to store this piece for just 'Field' / '[]-Array' or more data types for DictCollection as well?

Thank you very much for clarification, Shegit

[qwerty]

Just that you know someone read your post. But I have not the faintest idea what you intend with your model. It does not match any of my realities so I can't tell what should be doing or not.

q.

[Glassboy]

Just that you know someone read your post. But I have not the faintest idea what you intend with your model. It does not match any of my realities so I can't tell what should be doing or not.

It wasn't just me then.  I read it twice and then wondered if I was having a poor braining day.

[Shegit Brahm]

Thanks for your feedbacks.

I intend to model the code reality.

Because I see only the result using the software, my perspective is mainly from that GUI. Decisions made live via GUI have an effect what is possible in the following drop downs inside that gui.

So each time the gui is used to create a new object John..., it attributes for an object of this class got attributes with values.
That makes each time a John... as the class' instantiated object.
And if only that, a simple class with some attributes.
That simple part is summed up as "AttributeA"

Each John... object has 3 dropdowns that are dependent from each other:
- first the user decides which EnumType the current John... gets: Field, []-Array or DictCollection
- after that, the gui changes upon this selection:
-- it offers either
--- a simple field
--- or an expendible array-like list (with one value per entry)
--- or a collection like list (with two values per entry)
-- additionally the user has to use another dropdown to specify what data type can be used in all these entries:
--- for the single field: int or char => there is only one value stored of either these two types
--- for the []-array: int or char or double or String => multiple values can be stored, they have all the same data type (for each John... object, so different John... objects can have different data types for this array)
--- for the DictCollection: int or char or double or String or XML => multiple pairs of values can be stored, the first part of a pair has for each John... object the same data type, the second part of a pair can be different and is the same for each John... object.

(repeated):
Example:
JohnA: None=>Field | => char ='a' | AttributeA
JohnB: None=>Field | => int = 23 | AttributeA
JohnC: List=>[]Array | => String =["hello","world","list"] | AttributeA
JohnD: Diction=>DictCollection | => {XML, double} = {(<length>, 2.34); (<width>, 5.43)} | AttributeA
JohnE: Diction=>DictCollection | => {int, double} = {(4, 2.34); (32, 5.43)} | AttributeA

Which understanding do you get now? Thanks again for reading.

[Geert Bellekens]

Nope, still nothing, sorry

Geert

[Shegit Brahm]

thanks for trying, I try to rewrite the example:

JohnA:
- is one object so via GUI I say "create" and then a blank formular appears
- I chose name "JohnA"
- I set some AttributesA
- then I choose attribute "EnumType" with value "None"
- that displays a single Field
- before I can edit it, I have to choose the data type, I take "char" (int and char is possible)
- Now I can enter 'a' and save JohnA
=>  None=>Field | => char ='a' | AttributeA

JohnA:
- is one object so via GUI I say "create" and then a blank formular appears
- I choose name "JohnB"
- I set some AttributesA
- then I choose attribute "EnumType" with value "None"
- that displays a single Field
- before I can edit it, I have to choose the data type, I take "int"  (int and char is possible)
- Now I can enter '23' and save JohnB
=> JohnB: None=>Field | => int = 23 | AttributeA

JohnC:
- is one object so via GUI I say "create" and then a blank formular appears
- I chose name "JohnC"
- I set some AttributesA
- then I choose attribute "EnumType" with value "List"
- that displays an expandable array
- before I can edit it, I have to choose the data type, I take "String"  (int and char and String and double is possible)
- Now I can enter "hello", click "add entry", can enter "world", click "add entry", can enter "list"
- with saving JohnC has as an attribute an array from type String with 3 entries
=> JohnC: List=>[]Array | => String =["hello","world","list"] | AttributeA

JohnD:
- is one object so via GUI I say "create" and then a blank formular appears
- I choose name "JohnD"
- I set some AttributesA
- then I choose attribute "EnumType" with value "DictCollection"
- that displays an expendable Collection of paired values
- before I can edit it, I have to choose the data type, I take "XML" and "double" (int and char and String and double and XML is possible)
- Now I can enter "<lenght>" and "2.34", click "add entry", can enter "<width>" and "5.43"
- with saving, JohnD has as an attribute a collection of two pairs, each pair with two values of same data type
=> JohnD: Diction=>DictCollection | => {XML, double} = {(<length>, 2.34); (<width>, 5.43)} | AttributeA

JohnE:
- is one object so via GUI I say "create" and then a blank formular appears
- I choose name "JohnE"
- I set some AttributesA
- then I choose attribute "EnumType" with value "DictCollection"
- that displays an expendable collection of paired values
- before I can edit it, I have to choose the data type, I take "int" and "double" (int and char and String and double and XML is possible)
- Now I can enter "4" and "2.34", click "add entry", can enter "32" and "5.43", click "add entry", can enter "12" and "6.87"
- with saving, JohnE has as an attribute a collection of three pairs, each pair with two values of same data type
=> JohnE: Diction=>DictCollection | => {int, double} = {(4, 2.34); (32, 5.43);(12,6.87)} | AttributeA


My assumption is: JohnA-JohnE are objects of the same class - or the same superclass, not important.

Some new questions for clarification? :-o

[Geert Bellekens]

I see where you want wrong.
The "Attributes" you describe are not attributes at all.
Attributes are the properties of a class that are defined at design time. They have a fixed name and datatype at design time

What you are describing is some kind of generic "properties" system that can describe any sort of data structure.
I'm afraid you've fallen victim of the so called inner platform effect; google it 

Geert

[qwerty]

Huh, glad you figured it out, Geert It did not trigger anything with me except for a large question mark xD

q.

[Shegit Brahm]

I see where you want wrong.
The "Attributes" you describe are not attributes at all.
Attributes are the properties of a class that are defined at design time. They have a fixed name and datatype at design time

What you are describing is some kind of generic "properties" system that can describe any sort of data structure.
I'm afraid you've fallen victim of the so called inner platform effect; google it 

Geert

Thanks for your hint,
I understand it that way, that there is no live class modeling while software usage, there has to be "static" class modeling before the software runs.
- I guess that is the reason why someone suggested to make Class1 an abstract class and have three classes instead.


So I would say, my current suggestion has this flaw:
- the values of the instantiated object of any type Field, [] array or DictCollection cannot be stored anyhow because there is no attribute for it. and the data type of attributes to store values are dependent on other attributes to get theirs determined.

In ClassNone as the simplest case it already lacks it - so the "inner platform effect" happens already the moment I say "data type of attribute X depends on user decision" - is that effect understanding correct?

=> would it be useful to have a class for each possible data type combination?
- for ClassNone it would be ClassNoneInt and ClassNoneChar
... sounds a bit odd for DictCollection, even there are only pairs.

So how can I break the effect and get it straight forward? What should I research for?

Thank you very much, at least you could bring my "subconscious nonagreement" to light

[Geert Bellekens]

If you really want to continue down this rabbit hole, you should basically be modelling something like the UML metamodel.
Class, Enumeration, Association, Property, Datatype, these things.

Geert

[Shegit Brahm]

thanks again, will take a look. Thought I could concentrate on an UML model for this software only.

now I understand that I don't understand enough of the UML (class diagram) to model UML (class diagram).

[f]

Shegit Brahm, what you want to model is a decision graph, which should be modelled with activity diagrams. This diagram type is for modelling something along a timeline, because the arrow says you're moving on in time and the boxes are for situations. Class diagrams are structure views on your system, independent from time. I suggest you use a class diagram to show how your classes and objects must be built for the things you want to click in your GUI, but use activity or sequence diagrams to illustrate how your GUI moves from situation to situation and which choices are possible in every situation...

[benniesmift]

I think you mixed more things together. Dependency can be seen almost everywhere for instance, if an attribute has a type you can say that this attribute depends on its type. Dependency is the most general metaclass used usually to say: I won't to specify it more precious which doesn't mean it is wrong.

On the other hand, flow means that a piece of data flows from source to target. It doesn't say anything else such as who starts the transfer. Secondly, information flow is not from UML point of view a specialization of dependency.

Last but not least, multiplicity has nothing to do with dependency neither with information flow.

To sum it up: if you use information flow, there is no need to use dependency. Using multiplicity with dependency or information flow is against UML 2 standard. I would definitely delete the dependency if there is an information flow.