How would you create an uml class diagram for constructors with parameters?
For default constructors (no parameters) you do
policyholder() for the diagram and in the pseudo-code
For constructors with parameters would you do the same thing:
policyholder (policynumber, service class, and customer age) for class diagrams and pseudo-code.
It also asked to initialize each attribute to value where an object of this type can be instantiated. If a policy number is not between 1000 and 999 inclusive, then set the policy number to 0. (policy number is attribute)
The common way is to write constructors like methods and simply omit the return type.
If you want to be extra clear, you can add <<constructor>> in front.
Related
public abstract class Shape {
abstract int area();
}
How do we draw the UML class diagram for the abstract method? Use +, - or #?
public class Room {
int nWindows;
}
And what if the class instance variable doesn't have public, private or protected?
Abstract
According to UML specification:
The name of an abstract Classifier is shown in italics, where permitted by the font in use. Alternatively or in addition, an abstract Classifier may be shown using the textual annotation {abstract} after or below its name.
Note however that Operation is not a Classifier. It still has an isAbstract attribute as a BehavioralFeature but 2.5 specification does not define how to model the fact of being abstract. Older specifications (1.4.x) were using the same method as for Classifiers and it is a widely recognized method to show operation abstraction. Note only that the elements in curly brackets for features are presented at the end of line rather than just after the name (Classifier simply has no other specification directly after name).
Possibly authors made an omission in 2.5 specification for Feature abstraction notation by a mistake.
An abstract operation can of course have any visibility kind.
Of course the operation might be abstract only if its containing Classifier (Class in your case) is also abstract.
No visibility kind
In general visibility kind in UML is optional i.e. you can simply omit it. Just take into consideration that UML is a model so it actually can ignore some irrelevant elements or can specify them at a later stage of modelling. Not using any visibility kind in UML does not allow you to make any assumption about it's final visibility kind.
On the other hand if in actual code you use no visibility kind specification (if allowed at all) there is some default behaviour. For example
in Java it's package (#) - in UML understanding, Java calls it "package-private",
in C++ you'll end up with private feature (-),
in PHP such features are treated as public (+)
and so on.
I was going through basics of UVM tutorials. Everywhere I read the transaction objects are always extended from uvm_sequence_item and not uvm_transaction since uvm_sequence_item has additional features like transaction id, etc. If that is the case, why is the uvm_transaction class even there in the UVM class hierarchy?
Who is using uvm_transaction other than uvm_sequence_item extending from it?
Is it because of legacy?
This is what the UVM Class Reference says about this:
"The uvm_transaction class is the root base class for UVM transactions. Inheriting all the methods of uvm_object, uvm_transaction adds a timing and recording interface.
This class provides timestamp properties, notification events, and transaction recording support.
Use of this class as a base for user-defined transactions is deprecated. Its subtype, uvm_sequence_item, shall be used as the base class for all user-defined transaction types."
If you refer uvm class hierarchy (Link:[https://www.google.co.in/search?biw=1366&bih=620&tbm=isch&sa=1&btnG=Search&q=uvm+class+hierarchy#imgrc=Laxc9UWNpnGTpM%3A][1] ) then you find out that uvm_transaction parent class while uvm_sequence is child class.
So, child class can access all the property of parent class.
But parent class can not access child class property.
uvm_sequence_item has its own functionality like get_sequencer_id,set_sequencer_id, get_root_sequence.
These methods used by sequencer internally in case of layer sequences.
You call sequence by start method, uvm_do family or config_db.
Each of these method call start_item(req) and finish_item(req).
task start_item(uvm_sequence_item item)
task finish_item(uvm_sequence_item item)
If you observes data type in first argument in both the function is uvm_sequence_item.
There are total eight uvm classes.
(1) uvm_driver.svh
(2) uvm_push_driver.svh
(3) uvm_sequencer.svh
(4) uvm_push_sequencer.svh
(5) uvm_sequencer_library.svh
(6) uvm_sequencer_analysis_fifo.svh
(7) uvm_sequence.svh
(8) uvm_sequencer_param_base.svh
These classes are parameterized with uvm_sequence_item not with uvm_transaction.
If you use uvm_transaction instead of uvm_sequence_item then ti will shout an error(set_sequence_id not found which is property of uvm_sequence_item not uvm_transaction ) from uvm_sequencer_param_base.svh.
So, communication of sequence,sequencer and driver is not completed.
In most of the cases which I observe if you have a code in which you are not going to use uvm_sequencer then you can use uvm_transaction it will not shout an error.
But if your code contains uvm_sequener and you use uvm_transaction then it will shout an error (Could not find member 'set_sequence_id').
Note that from uvm_transaction class, uvm_sequence_item as well as uvm_objects are inherited. So, the static behaviour and non-static behaviour (so to say) class hierarchy all starts from uvm_transaction.
Now, I can add whatever functionality I want to, to uvm_sequence_item so that every inheritor of uvm_sequence_item can get this. I can do this without modifying uvm_transction_item. Otherwise, any change in uvm_transaction would lead to unwanted functionality in the component class hierarchy (static behaviour) and can even lead to unintended side effects.
PS: one of the difference between other OOPs languages and SV is that multiple inheritance is not allowed in SV. For example, in case of C++, I can inherit from 2 classes in a new class. This is not allowed in SV. So, the only way one can get the properties of uvm_transaction as well as from uvm_sequence_item is by inheriting from uvm_sequence_item. This maybe the source of your confusion.
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.
The Scala API lists something called Abstract Value Members under some classes and traits. What are these things and how do they differ from what the API lists as Concrete Values Members?
An abstract value has a name and a type but no value. This value has to be provided by a concrete val definition in a subclass. In contrast, concrete value members do have a name, type and value defined. It is as simple as that. Scala' abstraction mechanisms are more general than Java's.
I think it is covered in the link provided by #I.K. http://www.artima.com/pins1ed/abstract-members.html
Abstract Value Members are simple abstract members, i.e. members that don't have a value. Note that they are NOT necessarily vals but defs are included as well.
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>'