port and interface reference ???

[stenl]

Does anyone have a link to a good explanation on ports and interfacec?

In particular, my questions are:

* What does a port represent in the source code?

* I had expected to define methods for a lollypop interface... why is that not available in EA?

Thanks!
-nets

[robocop]

Hi stenl,

* I had expected to define methods for a lollypop interface... why is that not available in EA?  

What, if you switch the lolli's appearance to an abstract class enabling You to insert attributes and op's as usual?

To do so, right-click the lolli model element and follow Advanced Settings -> Use Circle Notation (in EA 5.0, can't remember the howto for earlier versions ...). To propagate the interfaces attributes and operations to a realizing class, redraw the realization arrow from the realizing class/component to the interface.

Hope, it helps!


PS: Unfortunately, the interface properties dialog doesn't supply an Detail-tab to insert attributes and operations directly (available for implementation classes only, as far as I can see). Still, You can add att's and op's using the context menu by right-clicking the interface model element (in EA 5.0).

[thomaskilian]

Still, You can add att's and op's using the context menu by right-clicking the interface model element (in EA 5.0).

Or simply by F9 (attr) and F10 (ops).

[SF_lt]

circle notation isn't UML2 native

I also haven't managed to get provided or required interface representations in EA 5

As I understand, interface is a public class method. So, if you have many public methods, you will have many interfaces. Port can be used Logically to group interfaces - port acts as a door, one or many interfaces can use one port.
Port is used in composite elements, when element's internal elements provide some interfaces for external use. Composite element acts as a proxy, so it needs to have the same interfaces as internal elements provide.

[robocop]

As I understand, interface is a public class method. So, if
you have many public methods, you will have many interfaces.


Well, not really!
An interface is a collection (namespace class or interface according to language) of public methods and attributes accessible to clients requiring these methods for usage. An interface is not implementing any method. Hence, an implementation class is needed to realize the interface (and so, all methods offered). That means, that an implementation class has to code out the operations with proper functionality. An interface may provide just a single operation, but usually, there's many more.

Why using an interface, if the methods can also be accessed by using the public methods of the implementation class directly?

Well, there could be several implementations of just this interface. So, the caller (requestor) using an interface is shielded against a special implementation. This makes it easier to e.g. exchange implementations while leaving the interface as it is!



Samples (Pseudo-Code):

+++++++++++++++++++++++++++++++

Interface-Declaration in C++:

class IProvider
{
public:

    int  providedAtt1;
    int  providedAtt2;

    void providedOp1(int iArg) = 0; // pure virtual -->  makes IProvider an abstract class
    void providedOp2() = 0;         // pure virtual --> makes IProvider an abstract class
}

Implementor (realization):

class Provider1 : IProvider
{
public:

    void providedOp1(int iArg) = { ... } // inline implementation
    void providedOp2() = { ... }         // inline implementation
}

class Provider2 : IProvider
{
public:
    void providedOp1(int iArg) = { ... } // inline implementation
    void providedOp2() = { ... }         // inline implementation
}

+++++++++++++++++++++++++++++++

Interface-Declaration in Java:

interface IProvider
{
    int  providedAtt1;
    int  providedAtt2;

    public void providedOp1(int iArg);
    public void providedOp2();
}

Implementor (realization):

public class Provider1 implements IProvider
{
    void providedOp1(int iArg) = { ... }
    void providedOp2() = { ... }        
}

public class Provider2 implements IProvider
{
    void providedOp1(int iArg) = { ... }
    void providedOp2() = { ... }        
}

+++++++++++++++++++++++++++++++

Interface-Declaration in C#:

interface IProvider
{
    int  providedAtt1;
    int  providedAtt2;

    public void providedOp1(int iArg);
    public void providedOp2();
}

Implementor (realization):

public class Provider1 : IProvider
{
    public void providedOp1(int iArg) = { ... }
    public void providedOp2() = { ... }        
}

public class Provider2 : IProvider
{
    public void providedOp1(int iArg) = { ... }
    public void providedOp2() = { ... }        
}

+++++++++++++++++++++++++++++++

Regards,

robo

[SF_lt]

... and what about ports?

[robocop]

Hi SF_It,

I'll work on a sample ...

In the meanwhile, there's a nice article worth reading (from 2003, but still up to date, see link  
http://www.uml-forum.com/docs/papers/IEEE_SW_Jul03_p57_Kobryn.pdf) explaining the usage of ports
in architectural design.

Cheers,
robo

[robocop]

Hi,

I uploaded some code samples (given in C++) on component ports and class ports at http://sharepoint.knowledgerecovery.com/external/eaug/Shared%20Documents/Forms/AllItems.aspx.


In the component port sample, the port is in fact an implementation class realizing some interface. For callers, the port is the only entry to the component system. The component itself contains local classes (-> parts), which are not accessible to clients.

As the component port sample is fairly easy, the class port sample is kind of 'weird'. The construction uses inner classes and is quite complicated. It's because the encapsulated class needs a reference of the encapsulating (outer) class to gain access to its private members (att's, op's, private parts and so on). A similar technique in Java would probably result in an easier sample ...

To be honest, I can't see any advantage in using ports on classes at implementation level. Quite a lot of code and unnecessary overhead ...

Other opinions welcome  :-/

robocop