In an interface method I want to have a collection of SomeType as an input parameter. How do I represent that within a Class Diagram in EA?
I tried using "SomeType[]" as parameter type, but EA doesn't seem to keep track of this: for instance when I rename the class SomeType to something else, the change doesn't propagate here.
You can specify multiplicity for each parameter of your method.
Parameter multiplicity is not directly visible in the class diagram even if you select "Full detail" in Parameter visibility in Diagram properties. But it is in the model.
The answer is unfortunately: you can't. EA does store the name only and not the reference to the class when you specify a parameter. There are other places where that's also the case (I currently can't recall where). So if you need to track that you need to write a smart SQL to list the used parameters.
Such a SQL could look like:
SELECT * FROM t_operationparams where Type = '<Search Term>'
Related
I am not sure which relationship between classes would be adequate for a class which returns a created object or gets an object as parameter(see uploaded picture). I guess that aggregation/composition is wrong since Class1 does not own the object/does not have it as an attribute. Also I think that an association is wrong since Class1 does not refers to a pointer.
Thank you in advance for any answers.
That would simply be dependencies:
An association is created in case you have a stronger relation between classes. That is either one is holding a more permanent relation (in form of an attribute) rather than a temporary one like in using them as passing parameter or return parameter. From an UML point of view an association is basically a stronger form of a dependency.
Note that the untyped attributes you sketched are of no interest in this context and I just left them out.
According to a comment of #www.admiraalit.nl: If Class1 creates new instances of Class3, the dependency may have the ≪create≫ stereotype, see table 22.1 of the UML spec. v2.5.1. In that case the dependency would be a usage (chap. 7.8.23) which is just a bit stronger
a class which returns a created object or gets an object as parameter(see uploaded picture)
you mean for a class having an operation returning ... and an other getting ...
I guess that aggregation/composition is wrong since Class1 does not own the object/does not have it as an attribute
you are right
Also I think that an association is wrong since Class1 does not refers to a pointer.
whatever by pointer or by value (which is target language dependent) an association is not right because there is no attribute in Class1 whose type is Class2 or Class3
The only possible relation between Class1 and Class2 or Class3 seems to be a dependency, but to have them does not have a real plus value, the profile of the operations already give that information
In the title I provided use-case for the following behavior: the field should be publicly mutable and immutable for the class's own methods. Consider also that I essentially want single line per field, because the number of fields may be great. Also I want to have no-arg constructor.
The nearest I can think of that could satisfy what you want is to have a trait which only has accessor methods, and an implementation class that allows mutations. Pass the class type around wherever you need to be able to alter values, but reference it only as the trait wherever the values should be unalterable.
Is the following format wrong if I add a pointer to an object of a class, as data attribute of class in Class diagram in UML?
could not find anything about using objects in class diagram, is
underlining the object correct within the class attributes?
I think you may be mis-understanding classes, objects and attributes. Apologies if it's me doing the mis-understanding. So. Here's the short answer:
it's absolutely fine and normal for the type of an attribute to be a Class. In other words, you're not restricted to using primitive types like int, long, char etc.
The consequence is, as you say, that the values of those attributes at run time will themselves be objects. Specifically, instances of the classes Ability, Move and See.
More specifically, each instance of Agent (i.e. each Agent object) will hold references - or more precisely pointers - to 3 other objects: one instance each of Ability, Move and See.
So, assuming that's right, what you have is correct - except for the underlining.
Underlining an attribute or operation says it sits at the class level - not the instance level. It's the equivalent of static in java. Think of declaring constants in class scope, or constructors.
If I understand your model that's not what you want. You want each instance of Agent to hold (a pointer to) its own instances of Ability, Move and See. You don't want all the Agent objects to share the same 3 instances. Assuming so, you don't need the underline.
Hope I understood and that helps.
I have a little bit of a curve ball for you. Maybe just a design issue...maybe even something as simple as me not understanding Data annotation providers.
Anyway here we go:
I have a class which represents some model data. Let's say it represents a package/box/carton.
It actually represents all of these things so I use the class in several different views. Sometimes I want the attribute of the field Package_Description to be
So that it shows up as Box Number : input box here.
Now if i want it to appear as "Carton Name" my only option would be to sub type it. Or use a separate class to have the annotations for this class. My quandary is that some of the field names are user configurable and therefore I cannot have a static definition!
(By the way i am using third party librarys [Telerik MVC Grid] do display these field names so i cannot change the fact that it's looking at data annotation )
So I just need to know is there a way to add attributes dynamically?
Create an anonymous type on the fly, sub class the original and then add attributes using reflection?
Or what other options are open to me, do I need to somehow implement a different annotation provider?
Attributes are part of the definition of the type. Because of that, you can't modify attributes of existing classes during runtime.
You could create a new type during runtime (not an anonymous type), but I think that's not such a good idea. I'm sure whatever component you're using, it allows you to specify the appearance explicitly.
As we know, Scala generates getters and setters automatically for any public field and make the actual field variable private. Why is it better than just making the field public ?
For one this allows swapping a public var/val with a (couple of) def(s) and still maintain binary compatibility. Secondly it allows overriding a var/val in derived classes.
First, keeping the field public allows a client to read and write the field. Since it's beneficial to have immutable objects, I'd recommend to make the field read only (which you can achieve in Scala by declaring it as "val" rather than "var").
Now back to your actual question. Scala allows you to define your own setters and getters if you need more than the trivial versions. This is useful to maintain invariants. For setters you might want to check the value the field is set to. If you keep the field itself public, you have no chance to do so.
This is also useful for fields declared as "val". Assume you have a field of type Array[X] to represent the internal state of your class. A client could now get a reference to this array and modify it--again you have no chance to ensure the invariant is maintained. But since you can define your own getter you can return a copy of the actual array.
The same argument applies when you make a field of a reference type "final public" in Java--clients can't reset the reference but still modify the object the reference points to.
On a related note: accessing a field via getters in Scala looks like accessing the field directly. The nice thing about this is that it allows to make accessing a field and calling a method without parameters on the object look like the same thing. So if you decide you don't want to store a value in a field anymore but calculate it on the fly, the client does not have to care because it looks like the same thing to him--this is known as the Uniform Access Principle
In short: the Uniform Access Principle.
You can use a val to implement an abstract method from a superclass. Imagine the following definition from some imaginary graphics package:
abstract class circle {
def bounds: Rectangle
def centre: Point
def radius: Double
}
There are two possible subclasses, one where the circle is defined in terms of a bounding box, and one where it's defined in terms of the centre and radius. Thanks to the UAP, details of the implementation can be completely abstracted away, and easily changed.
There's also a third possibility: lazy vals. These would be very useful to avoid recalculating the bounds of our circle again and again, but it's hard to imagine how lazy vals could be implemented without the uniform access principle.