I have a constructor that receives multiple parameters so it is a line a bit long. I'm working on the UML diagram for the class but I'm not sure if I could break the line and continue on the next one so that the class box does not take that much room. Probably this is something that has been asked before, but I haven't found a good reference on what to do in this case.
public Product(String name, int code, int price, int quantity,
int minQuantity, int maxQuantity) {
super();
this.name = name;
this.code = code;
this.price = price;
this.quantity = quantity;
this.minimumQuantity = minQuantity;
this.maximumQuantity = maxQuantity;
}
The UML specification does not specify whether wrapping the text on multiple lines is allowed or not. Because it's not forbidden, I would say it is allowed.
Personally, I would not show long parameter lists in class diagrams. A class diagram should primarily give an overview of classes and their relationships. To publish the details of the operations, it is usually better to generate textual documentation from the source code.
9.6.4 of UML 2.5.1 (page 118) states
The parameter list may be suppressed.
or even better, you may suppress the complete list of operations.
9.2.4.1 of UML 2.5.1 (page 101) states
Any compartment may be suppressed.
Related
How is an attribute with initial value (such as a static constant) represented in UML?
public class Foo {
public static final int BAR = 17;
}
The initial value of an attribute in a UML class diagram is represented just like variable assignment in a language like Java.
Moreover, since the example attribute is static, it should be underlined. Capitalization is by language or other convention and is not a UML specification.
I have doubts about where I should check my invariants...
For example, I have a Question aggregate with the following invariant:
The question's text must be not null
The question's text must have a length between 100 and 500 characters
I have read that the best place to check the invariants is in aggregate's constructor, but I have also read it would be recommended push domain logic in value objects, for example.
A possible aggregate's implementation could be:
public class Question {
private final id: QuestionId;
private final text: QuestionText
public Question(id: String, text: String) {
// verify invariants
ensureLengthText(text); // this method verifies the invariant
this.id = new QuestionId(id);
this.text = new QuestionText(text);
}
}
QuestionId and QuestionText are value objects.
In this case, in the aggregate we can see the invariant explicitly.
But, if we push that invariant logic in QuestionText value object, in the aggregate we will not see that invariant... then, what would be the best approach?
If you can easily enforce an invariant (e.g. "Question texts cannot be shorter than 100 characters nor longer than 500 characters") in a value object, I recommend doing so. Question inherits that invariant (and any and all others from QuestionText) by saying that text is a QuestionText.
Just wonering how would one represent an array as a state & return from a method in a UML diagram, here is what I'm doing right now:
- arr : String[16]
+ getArr() : String[16]
is this correct?
Holding that arr is a private non-static variable and GetArray() is a public non-static method, I would say this will suffice (different teams have different ways of documenting so this is an opinion). Some people don't include the array length in the class diagram, some do (that is your call). If your method has paramaters, I recommended you do something like this:
getArray([in] param1 : dataType, [out] return1 : dataType)
I am not even sure it's called pattern matching, but I would like to do something similar to there rules:
I have "objects" that have a "capability" attribute which is a sequence of names separated by spaces. For example:
a.capability = "" // no pattern
b.capability = "foo"
c.capability = "bar"
d.capability = "foo bar"
e.capability = "bar lol truc bidule"
(assume that each object must have a different pattern than other objects)
Then I have a global context object which also have such attribute:
context.capability = "" // 1
// OR
context.capability = "foo" // 2
// OR
context.capability = "bar" // 3
// OR
context.capability = "bar foo" // 4
// OR
context.capability = "lol" // 5
Now, we want to select only one unique object that "best match" the context capability.
For this we follow this rule:
if an object have no pattern AND the context have no pattern, this object is selected;
if an object have no pattern AND the context have a pattern, this object is selected if no other object matches;
if an object have exactly the same pattern names as the context, it is selected;
the object with the most count of pattern names contained in the context patterns is selected;
For example:
in context case 1) : a would be selected;
in context case 2) : b would be selected;
in context case 3) : c would be selected;
in context case 4) : d would be selected;
in context case 5) : e would be selected;
I'm writing this without even testing if this rules works, it's just an draft of what I would like to define.
My questions:
How do you call this kind of algorithm? (to allow me to do future research with the right name)
Are there already defined such a rules? It looks generic enough that someone could have defined similar rules before, but I can't find anything like that other than parts of language standard defining overloading rules (like the C++ standard);
Are there studies exploring the properties of such algorithm/rules? I an not certain that it's the right way to go for my use case but it seems likely the right solution. However I have no experience implementing this kind of language feature so I would like to see some data on what problem I might expect (but I can't find anything so far).
A friend suggested to look into some books about AI, expert systems and language designer and compiler implementation. However some guidance on how to find data on this particular way of doing would help a lot.
I don't have a direct answer to your question, but after thinking about it there's several ways in which I could frame the problem:
Document retrieval (such as used in search engines -- how do they rank disjunctive queries so quickly?)
Non-metric nearest neighbor (link is for the common metric version)
0-1 linear programming
As such, I don't think there's one term for this problem -- it's too interesting to too many fields. There's certainly plenty of studies between the three fields (e.g. Google):
Document retrieval
Non-metric nearest neighbor
0-1 linear programming
The Alloy 4 grammar allows signature declarations (and some other things) to carry a private keyword. It also allows Allow specifications to contain enumeration declarations of the form
enum nephews { hughie, louis, dewey }
enum ducks { donald, daisy, scrooge, nephews }
The language reference doesn't (as far as I can tell) describe the meaning of either the private keyword or the enum construct.
Is there documentation available? Or are they in the grammar as constructs that are reserved for future specification?
This is my unofficial understanding of those two keywords.
enum nephews { hughie, louis, dewey }
is semantically equivalent to
open util/ordering[nephews] as nephewsOrd
abstract sig nephews {}
one sig hughie extends nephews {}
one sig louis extends nephews {}
one sig dewey extends nephews {}
fact {
nephewsOrd/first = hughie
nephewsOrd/next = hughie -> louis + louis -> dewey
}
The private keyword means that if a sig has the private attribute, its label is private within the same module. The same applies for private fields and private functions.
In addition to the previous accepted answer, I'd like to add some useful insights coming from a one-week experience with Alloy on enums, in particular on the main differences with standard sig.
If you use abstract sig + extend, you'll come up with a model in which there are many sets corresponding to the same concept. Maybe an example could clarify it better.
Suppose somthing like
sig Car {
dameges: set Damage
}
You have the choice to use
abstract sig Damage {}
sig MajorDamage, MinorDamage extends Damage {}
vs
enum Damage {
MajorDamage, MinorDamage
}
In the first case we can come up wiht a model with different MinorDamage atoms (MinorDamage0, MinorDamage1, ...) associatet to Cars, while in the second case you always have only one MinorDamage to which different Cars can refer.
It could have some sense in this case to use an abstract sig + extend form (because you can decide to track different MinorDamage or MajorDamage elements).
On the other hand, if you want to have a currentState: set State, it could be better to use an
enum State {Damaged, Parked, Driven}
to map the concept, in order to have exactly three State to which each Car can refer to. In this way, in the Visualizer, you can decide to project your model on exactly one of the states and it will highlight all the Cars associated to this state. You can't do that with the abstract + extend construct, of course, because projecting over MajorDamage0 will highlight only the Car associated to that Damage and nothing else.
So, in conclusion, it really depends on what you have to do.
Also, keep in mind that if you have an enum composed by X elements and execute
run some_predicate for Y
where Y < X, Alloy produces no instance at all.
So, in our last example, we can't have a Y < 3.
As a last note, enums don't always appear in the Visualizer if you use the Magic Layout button, but as I said previously you can "project" your model over the enum and switch between the different elements of the enum.