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.
Related
In an AST transformation, I am trying to detect whether a class Foo has nested classes and, if so, whether they are static or inner classes:
#MyTransform
class Foo {
static class A {}
class B {}
}
When I examine fooCn.innerClasses, both Foo$A and Foo$B are listed. ClassNode includes a method called isStaticClass, but by the Javadoc, this only tells me whether a nested class is declared within a static method (as a local class), not whether it is a "static class" by the JLS definition. Both a.staticClass and b.staticClass return false, and both a and b return Foo for outerClass.
How can I inspect the class nodes for Foo$A and Foo$B and determine that Foo$A is a static nested class?
The ClassNode representing each class has a property modifiers containing the modifier flags for the class; bit 4 (value 8) is defined as the STATIC modifier. The utility method java.lang.reflect.Modifier.isStatic(classNode.modifiers) will indicate whether the class is static nested or inner.
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:
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).