I want to visualize an situation with a few different objects, their relations and the values of their instance variables. Any idea which diagram type fits best for that?
Object diagram.
It's like a class diagram except the attribute boxes have values.
Also, the lines between objects are "links" not "associations". They're the actual link (FK, object reference, whatever) not the class of the link.
Related
I'm on Enterprise Architect 14. I have a component diagram containing an interface User and two classes Employee and Customer, which both realize interface User.
Furthermore I created two instances, one of each class and specified the values of the attributes via Features & Properties > Set Run State....
Next I created a component with 2 attributes, one of type Employee and one of type Customer. Then I created an instance of the component.
Now I would like to set run state of the component instance by assigning ArbitraryUser to the Employee attribute and ArbitraryCustomer to the Customer attribute of the component instance. According documentation this should be possible (see here).
At run-time, an Object instance can have specific values for its attributes, or exist in a particular state. To model the varying behavior of Objects at run-time, use instance values selected from the 'Select ' dialog and run-time states or run-states.
However I could not figure out how to do so. Can someone help me?
AFAIK that is not possible.
I'm not sure what the quote from the help really means, but I've only ever been able to type a value for the run state.
An partial alternative would be to use associations rather than attributes to model such relations. Then you can create a link as an instance of the association to relate instances of Employee or Customer with instances of a ArbitraryComponent.
This solution doesn't work for datatypes, but it seems a bit far fetched to start modelling instances of datatypes.
In my UML class diagrams I usually do object collections by placing the attribute name above the arrow that relates both classes (as opposed to the other notation that just adds the attribute with brackets indicating the multiplicity).
But I have cases in which there are more than one collection of the same kind of object. For example (a very simple example off the top of my head):
Let's say there is a course that has some students who applied for it (so I have a collection of students, let's say an attribute that is an ArrayList of Student, called "applied"). But also, I need to keep a separate collection of the students who actually attended the course (let's say, "attended": another attribute that is an ArrayList, or even a different collection type, like a Vector, of Student).
Should I just add all attribute names on the relationship line?
I'm looking to do this the standard UML way. Only clarifying this because I know UML rules can be flexible when we need them to.
UML does allow for multiple associations between classes using roles.
You would simply draw two arrows:
See here for a similar question where the diagram is taken from.
I am using inheritance currently in EF and feel like it is causing more issues than it is helping, especially with binding an aggregation of tables to a datagrid. I have given a screen of part of the model. What I am trying to do is bind FREQUENCY to a datagrid, and have the grid fields be based on the type of FREQ_POOL(which is a base class). So for instance, if I want a POOL_IA datagrid, then it would have those fields, as well as the few fields in FREQUENCY. I was using inheritance because it made since from an OO perspective. The alternative is to just have lots of 0..1 relationships that show the ability for FREQ_POOL to have an extension, but then I have no constraint in place saying that FREQ_POOL can only be ONE type. What is a better design to accomplish this and make data binding easier? Thank you for any guidance.
One approach may be creating a data grid that gets the data from FREQ_POOL and then put all the variables of POOL_IA (or the all the properties of derived class using reflection) and FREQUENCY .
If you really don't need using objects while binding your data grid and able to use DataSet the another approach may be getting all the properties and the values of entry with Context.Entry method on the fly and put it into DataSet dynamically.
I am new with Core Data and I experiment a design problem.
Suppose I have two entities : "Product" and "Image".
The Image entity has an attribute named "type" ( normal, mini etc...).
I would like that the Product entity has attributes of type Image like : miniImageList, normalImageList etc... but I really don't know if it is possible given that with XCode4 graphical editor, it is not possible to create an attribute whose type is an entity previously declared.
The only ugly solution I found, is to create a to-many relation between Product and Image. Therefore, I have an NSSet generated which contains all the images I wish.The problem with this solution is that I need to test the type of the image I wish ( mini, normal ) etc... which is not really handy.
If any of you know how to solve this problem, you're really welcome ;)
Hope I've been clear, thank's for reading.
I would like that the Product entity has attributes of type Image like : miniImageList, normalImageList etc... but I really don't know if it is possible given that with XCode4 graphical editor, it is not possible to create an attribute whose type is an entity previously declared.
For that, you need to create relationships. An "attribute of type Image" is essentially a relationship between Product and Image.
A more appropriate solution in your case, would be to define fetched properties between Product and Image. Thus, miniImageList and normalImageList can be defined as fetched properties using the "filtering" you need to apply on your Images set. An important limitation of fetched properties though, is that they are not dynamic. You would need to ensure that the contents of the resulting Image NSArray take into consideration the latest Image entity additions/deletions/modifications.
Either seperate the different image sizes to entitys or you expand your Image entity to hold diferent sizes of the graphic.
Seccond method would be best in this case I think. An Product would have a easy to follow reference to the Image entinity and its properties.
Let's take 2 UML class model entities: One represents an actual Order and another represents an Orede Type. Any Order corresponds to one Type. A 2-way-naviglabe many Orders to one Type relation is meant. Order Type instances are, for example, "Request availability", "Request price", "Preorder", "Buy", "Cancel", "Request support", etc. Order Types are to be addable and editable in the resulting application. Should I model Order Type as Class or as Enumeration? From the data perspective I can't see the difference actually.
I would prefer an enumeration. Classes should define properties and behaviour. In this case the type represents only a value with no need of methods.
Conclusion:
The usage of a class would surely possible but not necessary if you only want to represent values. Also, it would create a lot of extra coding work. You would have to write and maintain a bunch of classes that only represent one value when you could use an enumeration, which is surely the best and shortes way to represent typed values.