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)
Related
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.
I have a superclass called A and a subclass called B that inherits from A. The superclass's constructor looks like this:
A(String name, char displayChar, int hitPoints, Behaviour behaviour)
{
this.name = name;
this.displayChar = displayChar;
this.hitPoints = hitPoints
addBehaviour(behaviour);
}
A has attributes of name, displayChar, hitPoints, behaviour and has a method that calls addBehaviour which adds the behaviour to the object.
The subclass, B's constructor looks like this:
B(String name) {super(name, char 'b', 10, new WalkBehaviour()); }
Now my question is, does subclass B have an attribute of WalkBehaviour?
How would the UML diagram look like for this scenario? I know B inherits from A and A has Behaviour but does B has WalkBehaviour in this case? Since B doesn't have an instance variable of type WalkBehaviour in its class but only passes WalkBehaviour through its superclass's constructor.
does subclass B have an attribute of WalkBehaviour?
No. There is none declared. The superclass will do something with that new object but obviously it's hidden in the mist of its implementation.
Inheritance is nothing that involves multiple object creation. Your B instance is just a single one which does have attributes and operations like its super class.
Thus, in a SD, you will see only one life line for B:
As you can see the B instance will just issue a self-call to the super class's constructor.
Note: as #AxelScheithauer pointed out in the comment the super class will invoke addBehavior which can (but must not) be shown in the SD:
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.
I think I understand Value Objects ( they have no conceptual identity, set of its attributes is its definition etc) and how they differ from Entities, but I'm still puzzled whether a value of a primitive type ( int, string ...) being assigned directly to property of an Entity is also considered a VO.
For example, in the following code an object ( of type Name ) assigned to Person.Name is a VO, but are values assigned to Person.FirstName, Person.LastName and Person.Age also considered VO?
public class Person
{
public string FirstName = ...
public string LastName = ...
public int Age = ...
public Name Name = ...
...
}
public class Name
{
public string FirstName = ...
public string LastName = ...
public int Age = ...
}
thank you
It doesn't matter if a value is a primitive type (such as string or int) or a complex type composed of primitive types (such as Name). What matters is that you think of it as a mere "value" without any identity -- then it is a value object.
The decision to keep it a primitive or wrap it in a class is an implementation detail. Specific types are easier to extend in the future / add functionality than primitive types.
Check this related question... Value objects are more an implementation thing that a "conceptual" one... If you think about it, singleton and flyweight pattern are about turning an object with an identity to an value object for optimization purposes... It's also related to choosing to implement something as mutable or immutable. You can always say that Person is immutable, but after a while, you are a "new" person with different attributes. It's an implementation decision, not a domain or conceptual one. (Immutable things tend to be value objects, and the mutable ones identity objects).