As the title suggest what is the difference between the three and when should one use one of the three instead of the other two?
The internet is filled with their definition but i couldn't find any text or explanation on when and where to use required interface or the <<use>> dependency.
There are only two cases in fact: realize/use on the one hand, and provided/required on the other. They essentially describe the same thing, but with different emphasis.
With realize/use you draw visible relationships from the class (or component, as in my examples below) to the interface, and thus show the interface and its operations in the diagram.
You could, of course, split that into two different diagrams.
With provided/required, on the other hand, the interface is only shown as lollipops so you can't see the operations. But you can draw visible relationships (usually "assembly") between the lollipops.
I'd say that realize/use is more appropriate if you want to show who implements what. Provided/required is more appropriate if you want to focus more on interactions between parts.
A required interface is usually shown as socket. It means that in order to have the class working it needs at runtime a counterpart with a lollipop. This counterpart in turn offers the interface via a lollipop. To decouple class and interface definition you put the interface in a stereotyped class and draw a realization from the providing class to the interface. Vice versa you draw a dependency from the requiring class to the interface. Whether you stereotype the dependency with <<use>> is more a matter of taste.
as described above and as alternate representation:
Related
My component diagram is mostly components, ports, and interfaces. The interfaces have operations and attributes. They do not capture any class based OO at the moment. What's the right way of doing that?
My options as I see them is either:
Add the class constructors to the component interfaces, and let the type carry remaining details like class operations.
Duplicate class interfaces into the component interfaces, e.g. having the class object as first parameter.
From the two the former is least work obviously. But perhaps there is a better way I've overlooked.
Notation
The easiest way to do this is to capture the interfaces in a separate class diagram, with only «interface» classifiers. The advantage is that these classifiers give a (hopefully short) name to an interface, and describe the attributes and operations that are needed, with all required details, including constructors (keep in mind that in UML constructors should be preceded with «Create»)
You can then show for the components in your component diagram the interfaces provided (lollipop) and required (socket) just referring to the named interfaces, without cluttering the diagram with lots of redundant interface specifications.
Design
When you refer to duplicating class interfaces at the component level, I understand that you mean to add attributes (parts?) and operations to the component.
Of course, components implementing the same implicit interface could in principle be interchangeable. However, this approach does not allow to have a clear understanding of the dependencies, and in particular use dependencies, that are practical to decouple components. In other words, your components would be hard-wired.
Adding class constructors at the component level seems cleaner in this regard, since your class constructor would reuse classes that are defined somewhere else. But if you're going into that direction, you could go one step further and consider using a factory class:
The factory class constructs objects of a given class or a given interface
Your component would be initialized or configured with such factory provided from outside. The factories could be interchanged to construct different kind of objects that meet the requirements.
*. If you go that way, I come back to the notational topic: the lolipo/socket notation would then allow to highlight better the decoupling that this design would offer.
I didn't understand the options you describe. Maybe a diagram would help. Here is how I would do it:
The specification component has two ports and is indirectly instantiated. For the realization component I select two classes that are realizing the component. Class1 has an operation that uses the service defined by interface I1. Class2 implements the service promised by I2. Since port p2 has a multiplicity of 16, the part typed by Class2 also has at least this multiplicity. The constructors (with the «create» stereotype), don't have parameters, so that the component can be constructed without any additional logic.
If you need additional logic, you can use directly instantiated components. They have constructors that could call the parametrized constructors of realizing classes and also create the wiring.
I've been wondering how to model interface between two components using it's rectangular representation (not lollipop) with all the details (attributes, operations).
I have two components and interface that lets them to "talk" to each other.
Using "lollipop" notation I would do this in this way:
But I didn't know how to attach my interface definition to this flow.
Is it correct to attach it to the line of Information Flow? What type of assotiation use to do this?
I found in OMG specifiaction the following description.
The component providing the interface REALIZE it. The one that consume it - USES it.
Recreating the diagram gave me this state:
I do not understand the meaning of class in Modelica context.
From the Modelica Tutorial, version 1.4 on https://modelica.org/publications.html:
In Modelica, the basic structuring element is a class. There are seven restricted classes with specific names, such as model...". Anyone have a simpler explanation? I am very new to Modelica.
If you open the Modelica library in a tool like Dymola or OpenModelica, everything you see in the package or library browser are classes.
As soon as you use one of these classes, e.g. with drag and drop in the diagram layer, you create a new component of this class type.
The instantiated component is not a copy of the class, but a reference to it. Therefore, if you update the class definition, you also update the behavior of all components that are instances of this class.
There are several kinds of classes available. The most general class is actually called class, but it’s not used very often.
It has no restrictions, so it can contain everything that is possible with Modelica: equations, algorithms, public and protected components, etc.
There are more specific class types, which restrict the usage. This helps to make correct use of a class. A function or a record for example cannot be simulated.
The most important restricted class types are:
package: used to group other classes
model: typically used for components with physical connectors and for examples which are simulated
block: used for components with causal connectors (only inputs and outputs, so everything you have in Modelica.Blocks)
function: used for function calls, comparable to other programming languages
record: often used to contain data sets for other components (which allows to quickly change a complete data set)
connector: used to define the interface variables which are needed to connect different components of a domain (e.g. v and i in the electric domain)
type: typically used to define physical quantities like mass, length or time with their unit (e.g. all units in the package Modelica.Units)
More information can be found in chapter 4.6 of the Modelica specification: Specialized Classes
This is just a collection of links to prove that there is an ongoing discussion on class within the Modelica Association:
class still a valid Modelica class type to use?
model no longer identical to class
What is the usage recommendation for class?
Restricted class for parameter record with initial equation
Does any programming language provide such a thing?
Where could this be used?
For example:
note that somethingStrange is not a class, its an instance (its underlined) and this is an object diagram
Spec (section 7.3.22) says:
An instance specification is depicted using the same notation as its classifier, but in place of the classifier name appears an underlined concatenation of the instance name (if any), a colon (‘:’) and the classifier name or names.
The convention for showing multiple classifiers is to separate their names by commas.
So im stuck with "multiple classifiers".
Any language with extensional rather than intensional typing will allow such constructs.
For example, in RDF two sources could make claims about a web resource which are completely conflicting, or in a 'duck type' language an object could have all the characteristics of two otherwise unrelated types.
Extensional languages classify objects by their properties - if it has prongs it's a fork, if it's got a handle and a bowl it's a spoon, if it has both prongs and a bowl it is both a fork and a spoon.
The difference between such languages and class oriented intensional languages such as C++/Java/C# to which UML is more commonly applied, is that you don't need a spork class to define things which are both spoons and forks - whether things belong to a classifier is defined by whether they meet the requirements of the classifier.
That's multiple inheritance if you're referring to classes (except that you should use solid edges for generalization), nothing wrong with that ;)
Note that an interface is also a classifier, so also the text of your question needs a bit of refinement -- nothing wrong with generalizing more than one interface, after all.
It's is a Dependency.
Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time. One class depends on another if the latter is a parameter variable or local variable of a method of the former. This is different from an association, where an attribute of the former is an instance of the latter.
In other words your somethingStance class will use both Cat and Panzer
The below it is just an example of how it might look like
Public class SomethingStrange{
public Cat CatDependency{get;set;}
public Panzer PanzerDependency{get;set;}
}
UML does allow an object to be instance of several different classes (even if they are unrelated) at the same time. The fact that this is not the normal convention and not supported by programming languages is a different issue. UML tries to be as broad as possible even if specific technologies only can implement a subset of it.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Why are interfaces useful?
Actually, I have a [small] idea of why interfaces are useful/necessary but...
What are [interesting or realistic] applications of interfaces?
Interfaces are interesting because you can allow 2 classes to implement the same methods. Lets look at an example.
Say I have a base class called Animal. All animals breathe, and communicate. Now lets say I have 3 classes, called Dolphin, Human, and Tiger. All of theses animals breathe and communicate. But I want to implement a walking method for the Human and Tiger. Dolphins cant walk. So I inherit the IWalk method for the latter two, and when I compile the class, I HAVE to implement the methods specified in the interface, or it won't compile. It's a contract saying, "If I want to implement this class, I have to implement these methods."
One use that I have for interfaces is to help with unit testing framework classes that are hard to mock. I will create an interface that works basically the same as the framework class and a wrapper class that implements the interface. The constructor of the wrapper class takes an instance of the framework class as an argument. The wrapper delegates the interface functionality it supports to the framework class, but I implement to my interface instead of the framework. Using the interface makes it easy for me to mock out the wrapper class's functionality in my unit tests -- either using a mocking framework or by providing a fake class that also implements the interface and supplying it via dependency injection to any classes that would normally rely on the framework class.
They allow polymorphism without some of the bad sides of inheritance.
What do I mean by bad sides of inheritance?
Code and Data inherited down a long chain (making it less obvious).
Inherited members that are over-ridden somewhere in the inheritance tree.
How can you use polymorphism?
To avoid repeating yourself. Create functions, switches, or conditionals which use the interface instead of the objects that implement the interface.
Java Specific
In Java, it often makes sense to use interfaces as a way to get multiple-inheritance.
This makes sense if something naturally fits into two categories and you have separate behavior expected for both of them.
Some Java Examples from the Web
http://home.cogeco.ca/~ve3ll/jatutor5.htm
http://java.freehep.org/lib/freehep/doc/root/index.html
http://www.codeguru.com/java/tij/tij0080.shtml
An interface (or an abstract class) is a contract you pass with the compiler. This contract says :
-- Well, compiler, make sure that all the classes that will implement this will provide at least everything that is defined in this interface !
With this insurance, you can then write methods that manipulate objects of any class implementing this interface :
void myGenericMethod( IAnInterface genericObject )
myGenericMethod method can use any member of the interface IAnInterface. It will never throw a runtime error (any missing member will have been caught by the compiler).
Utility : to give some common behavior to different objects. You may want for example to be able to call a method named GetID on any of your objects, being it a BankAccount, a ComputerCluster or an AirplaneTrip.
You will find a lot of useful interface usages in most design patterns. MSDN provides some hints about when you should use an interface here : http://msdn.microsoft.com/en-us/library/27db6csx.aspx
As tvanfosson mentioned, there very useful for mocking, also if you writing a library that depends on outside configuration you can make an IFooProvider and have the calling program implement it.
I assume you mean "interface" in the programming language sense rather than in the other senses, e.g. "User Interface".
An interface in languages like Java or C# serves two purposes. The first is to provide a contract for a type to implement; a suite of method names and signatures that the type provides to other types that use it. The second is to provide polymorphism upon that interface for the type. For example, if I have a type that implements the IFoo interface, I can pass an instance of that type to another class where the other class needs only know about the IFoo interface rather than every detail of my class that implements IFoo.
Interfaces are useful when you want to allow interoperability between two classes that do not share a common class hierarchy.
A good example of this is java.lang.CharSequence. Lots of other things can be abstractly treated as strings, but it wouldn't be correct to subclass String to do so. In fact String is final so it couldn't be done anyway.
Some time around JDK 1.4 (I beleive?) the CharSequence interface was introduced. Now String, StringBuffer, CharBuffer and lots of other existing classes in the JDK implement it. With that, new methods could be added to other APIs which accept CharSequence, allowing them to abstractly handle all of these in a unified way.
You can also implement this interface yourself and use it the same way. It's far more flexible to implement a common interface than try and force things to extend from a specific base class (or sometimes it's impossible).
I prefer to regard an interface as a description of a role to be fulfilled by each instance of an implementing class, independent of any implementation inheritance hierarchy.
By way of analogy, you can describe a "screen pass" football play in terms of how certain positions on the team interact. That description, in terms of position (or role or interface) is independent of which player happens to be playing the position at a given time. It's also independent of whether the team happens to have some talented players who can play more than one position.
The advantage of interface-oriented thinking is that it puts the focus on the role that an object fulfills in a given interaction with other objects, without concern for any other roles the object may play in other kinds of interactions. It also allows testing to focus on scenarios that are relevant to a role (and to mock or fake roles in a test scenario).