Section 12.2.8 of the IEEE UVM talks about the uvm_tlm_fifo classes. I was wondering why we need the exports put_export and get_peek_export?
The same put and get methods can be used on the fifo directly, why would I need to use the interface methods?
Thanks in advance :)
The point of using TLM exports is removing dependancies when making connections. put and get of the uvm_tlm_fifo component are the method implementations, while the exports are just interfaces.
When you embed a fifo inside another component, you can call the implementations directly without making any connections as a shortcut. But if you want to have another component make a connection, the TLM principle abstracts away the existence of the FIFO and makes you connect to a generic put or get export.
Related
Since I have not yet completely understood the correct usage of port and interface symbols in component diagrams, a few questions:
I.
Imagine a piece of software which wants to use a very special remote logger service over network (TCP). The messages may be some XML. So the logger exposes an interface which specifies things like handshake, XML structure, XML elements etc. so that the logger will accept a message.
a) Am I right that this interface may be called "ILoggerProtocol", the port may be named after the service it provides ("logging")?
b) So the component in my application implements that interface so that it generates a compliant message for the server?
c) Now an interesting thing: for the communication, there is an additional library "Networking" which provides simple TCP stuff, so it does the TCP connect, sends messages, handles errors etc. Do I need this class when I only want to emphasise the way from the generated messages to the server? Is then MY port the TCP interface?
d) And when I want to draw the complete picture, how can I add the Networking component to the diagram correctly, pointing out that ILoggerProtocol is used AND that it goes over TCP through the Networking component?
II. Ports inside my application: now there are two libraries where one just uses the other; basically, in C/C++, it would #include the other's header file:
e) Is that the correct diagram?
f) Do I need ports here? If yes, what would they actually represent in reality? What names would you give them?
g) Or are the lollipops just sufficient without the port symbols?
III. concerning lollipops:
h) are those two notations basically the same and interchangeable? I have found the name "assembly" for the combined version, so maybe there is a difference...
A short answer first (trying to rip up the rest later): a port is an embedded element which allows to group a number of interfaces. The best I can come up for an example is a complex socket (the port) which bundles things like power supply, communication lines, you name it (the interfaces).
Now for the details.
a) Yes, that's correct. You would usually use a <<delegate>> stereotyped association to show that the outer interface is used(/realized if it's a lollipop) somewhere inside.
b) No. This is a required interface. It is used inside but implemented outside (where the lollipop resides).
c&d) I'd use a <<use>> from MyApplication towards Networking to show that. Normally you would not go into too much detail (unless it is essential). Obvious things like TCP are clearly pictured with the <<use>>
e) You can(/should) use <<include>> or <<use>> instead.
f&g) see the general answer above
h) Yes. The first is a flexible notation of the second.
P.S. Just looking over this once again and I notice that in the top picture the inner directed association should be pointing the other direction and be stereotyped <<delegate>>.
Since WinRT exposes both the IStorageFolder interface and the StorageFolder class, my reflex was to use the interface throughout my code. I reasoned that IStorageFolder could be used as an abstraction to support non-filesystem folders like those in compressed archives. However, looking at the IStorageFolder interface, every method is declared to return concrete StorageFolder instances. As such, it would not be possible to implement a virtual filesystem based on this interface.
So how is IStorageFolder a useful abstraction? Or does its existence have a technical justification?
It is an interface because there are two implementations of IStorageFolder: One is StorageFolder, and another is FolderInformation. Since there are two implementations, the common behavior uses an interface so that you can write a function that operates on either StorageFolder or FolderInformation.
From a design point of view, can I say that Interfaces are used to produce flexible code open for future easy maintenance. Referring to the case study, am I right to say:
Interface in this example is used because both Professor and HeadofDept class have the power to employ people. Assuming that we might add other people who might be given the right to employ people in the near future.
Thanks for your attention.
Interface will allow your code to call methods like employPeople() on the base type i.e EmployerProfessor. So you pass around EmployerProfessor objects and code need not know what the exact implementation is, it just knows that it can call employPeople(). So it allows for dynamic dispatch of method calls. Using some compiler implementation (vtable etc) it will call the correct method for you.
Interfaces are not always so flexible, its difficult to go and just change an interface since current code in the wild may be affected. An interface provides a contract, it tells the class implementing it, that you must provide the following methods.
Before I start using CORBA I want to know something.
It would seem intuitive to me that you could use an IDL type as an attribute of another, which would then expose that attribute's methods to the client application (using ".") as well.
But is this possible?
For example (excuse my bad IDL):
interface Car{
attribute BrakePedal brakePedal;
//...
}
//then.. (place above)
interface BrakePedal{
void press();
//...
}
//...
Then in the client app, you could do: myCar.brakePedal.press();
CORBA would seem crappy if you couldn't do these kind of multi-level
object interfaces. After all, real-world objects are multi-level, right? So can
someone put my mind at ease and confirm (or try, if you already have CORBA set up) if this definitely works? None of the IDL documentation explicitly shows this in example, which is why I'm concerned. Thanks!
Declaring an attribute is logically equivalent to declaring a pair of accessor functions, one to read the value of the attribute, and one to write it (you can also have readonly attributes, in which case you would only get the read function).
It does appear from the CORBA spec. that you could put an interface name as an attribute name. I tried feeding such IDL to omniORB's IDL to C++ translator, and it didn't reject it. So I think it is allowed.
But, I'm really not sure you would want to do this in practice. Most CORBA experts recommend that if you are going to use attributes you only use readonly attributes. And for something like this, I would just declare my own function that returned an interface.
Note that you can't really do the syntax you want in the C++ mapping anyway; e.g.
server->brakePedal()->press(); // major resource leak here
brakePedal() is the attribute accessor function that returns a CORBA object reference. If you immediately call press() on it, you are going to leak the object reference.
To do this without a leak you would have to do something like this:
BrakePedal_var brakePedal(server->brakePedal());
brakePedal->press();
You simply can't obtain the notational convenience you want from attributes in this scenario with the C++ mapping (perhaps you could in the Python mapping). Because of this, and my general dislike for attributes, I'd just use a regular function to return the BrakePedal interface.
You don't understand something important about distributed objects: remote objects (whether implemented with CORBA, RMI, .NET remoting or web services) are not the same as local objects. Calls to CORBA objects are expensive, slow, and may fail due to network problems. The object.attribute.method() syntax would make it hard to see that two different remote calls are being executed on that one line, and make it hard to handle any failures that might occur.
A dual interface in COM is one that is able to be accessed via a DispInterface or via VTable methods.
Now can someone tell me what is exactly what the difference is between the two methods?
I thought that a VTable is a virtual table which holds the pointers to the different functions when implementing a class hierarchy which has virtual functions that can be overridden in child classes. However I do not see how this is related to a dual interface in COM?
In short, COM is binary specification, not a language specification. There really isn't a correlation between dual interfaces and deriving classes in code. Apples and oranges.
The VTable is "early bound" and this therefore faster. You know the type of method you are calling at compile time.
Using the DispInterface is "late bound" and is therefore slower, but more flexible. It's used extensively for scripting. The method and property types are determined at runtime.
I hope this brief explanation helps.
The main difference is in the way of calling object methods. In the case of DispInterface call goes through IDispatch::Invoke method (used in scripts or in the absence of the interface description) see remarks. This method is much slower second option. In the second case used directly VTable for method calls (used for calls from C + + or. NET languages)
I want only answer to additional Tony's questions.
If you want create a COM which can be accessible from VBScript/JScript or from old "classic" ASP you have to implement IDispatch.
In Visual Basic 6 or in VBA of MS Office one can use both ways. If you add Reference to your COM, then you will be use "early bound" (IUnknown or VTable). If you use your COM in VB6 or VBA with CreateObject ("ProgIdName"), that you will be use "late bound".
It is very important to understand, that to make COM accessible from VB6/VBA ect. it's not enough just implement IUnknown interface. You have to create and register Type Library with oleautomation attribute. To be able to do so, you can use in the interface of your COM only oleautomation compatible data types (see http://msdn.microsoft.com/en-us/library/aa367129%28VS.85%29.aspx). For understanding the type library play a role of client marshaling DLL, so it helps a client software like VB6/VBA to send correctly data as a parameters to your COM. You should don't forget, that even your COM will be an InProc server, a DLL, parameters will be not forwards directly to COM, but need be marshaled. During marshaling a copy of data will be created on the thread where run your COM. It makes your COM DLL thread safe from one side and you COM will be not crash if the thread calling your COM method will be ended before COM returns the value.
Probably my explanation about marshaling is not easy, but it's just important don't forget to create and register the Type Library which is better to save as a resource inside of COM.