Author Topic: Components and Interfaces  (Read 925 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5882
  • Karma: +71/-79
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Components and Interfaces
« on: September 16, 2005, 08:43:39 pm »
The topic: Composite vs Component
got me thinking about the way I emit Interfaces...

UML2 provides for a formal Interface Classifier.  When such a Classifier is defined stand alone, it seems to me it just IS...

When the Interface is attached (more like embedded in)  to a Component then it needs to be qualified as to whether it is a Required Interface, a Provided interface or both.

Have I got this right? Any other issues I should consider when emitting Interfaces?

TIA,
Paolo

Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Components and Interfaces
« Reply #1 on: September 19, 2005, 06:07:27 am »
Not sure I understand the question...
Quote
When the Interface is attached (more like embedded in)  to a Component

Do you mean nested in... similar to a nested class?
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5882
  • Karma: +71/-79
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Components and Interfaces
« Reply #2 on: September 19, 2005, 06:49:03 am »
Quote
Not sure I understand the question...
Do you mean nested in... similar to a nested class?
Well no not really,

Over the weekend, I refactored my view of a Component.  It is currently modelled in my UMLPlus XSD as a Classified Collection\Container with Interfaces.

As an Element, it can be nested in a variety of other Elements, as an Element it may nest other Elements.
As a Container it may contain other Elements (Physical Component).
As a Collection it may include other Elements (Logical Component).
As a Classifier it holds Classifier information.
As a Component it may (must?) have Interfaces.

My point was really that Interfaces can have "lives of their own" but a Component may provide or require an Interface (whether pre-existing or not).  Thus the determination of whether an Interface is a required or provided one is determined by its relationship to another element (in this case a Component) than any intrinsic aspect of the Interface itself.

Feedback invited...

HTH,
Paolo

« Last Edit: September 19, 2005, 07:22:36 am by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Components and Interfaces
« Reply #3 on: September 19, 2005, 07:35:16 am »
Yes, I agree with your point.  However, and this a being picky,
Quote
As a Component it may (must?) have Interfaces.
 

I read as: "A component as a component...".  Seems a bit circular to me.  ;)

I think may have is technically correct, but to be a useful component, must have is more realistic; worthy of a warning message I think. ;D
Verbal Use Cases aren't worth the paper they are written upon.

Hans

  • EA User
  • **
  • Posts: 78
  • Karma: +0/-0
    • View Profile
Re: Components and Interfaces
« Reply #4 on: November 01, 2005, 03:42:30 pm »
No Paolo,

an interface boils down to an abstract class with ..yerkyerk.. add. behavior in yerkyerk language which will make it ..yerkyerk.. more special.

A component on the other hand never is abstract.

Cheers Detlef

PS: Where's the beef to UML when there's no common symbol for a WebService?