I have been going over some books and some articles to refresh my memory on class diagrams with UML.
I have stumbled upon something i have not known before and that's the lollipops and sockets relations (where lollipops are provided interfaces and sockets are required interfaces).
But I cant seem to wrap my head around when and why to use them.
From what I remember about interfaces and and class diagrams, the use of interfaces is done by A realization arrow (I create some interface and some other class will realize it).
So when will i want to use a lollipop association?.
The sockets show a uses dependency between some client classifier and the provider of the interface. This indicates that the client classifier uses any implementation of the interface.
UML lollipop (ball and socket)
It is a part of UML Component Diagrams
Socket - requires interface(consumer)
Ball - provides interface(producer)
You can use the "lollipops" to represent an interface of a component - typically in a component diagram. They are not used to attach them to all/any classifiers.
The Lolipop notation is used in the componenet digram.
As Far as i know, the lolipop can mean input and output
Where the socket (Half-Circle) reqiures input and the ball provides the input
Reference: OMG UML 2.5.1 specification, Retrived from: https://www.omg.org/spec/UML/2.5.1/PDF
Related
In Rhapsody, is it possible to draw a diagram like the following?
I can add ports and interfaces to classes, but Rhapsody doesn't seem to support the port concept for components.
Yes it is possible, but for Classes. Usage is possible in normal Class or Object Diagrams.
see:
IBM Manual "Managing Ports"
A "Component" in Rhapsody is different to an UML Component,
it represents a Executable or Library and therefore there is no special Component Diagram like your Example.
When part of my solution is to use already built classes (for instance,Java's API classes) to promote reuse's principle, how do i represent these in uml diagrams like class, sequence and activity diagrams? Is it more common to represent them on diagrams or to ommit them?
Of course you have different options. But usually I create component elements representing libs (and APIs). Those components can either hold the classes they implement directly or you can associate them (e.g. via a <<realize>> relation). It's a good idea to attach lollipops and sockets to the component to show the implemented and required interfaces. The latter can also be used in sequence diagrams.
I want to draw an uml diagram for two systems that communicate through network.
It is similar to client-server scheme. Client send an event and server process it.
What kind of uml diagram should I use to do that? Components diagram?
You can create component elements to represent your systems and than you can use sequence diagram to define how your systems communicate. For communicating system involved in interaction defined in sequence diagram use lifeline. Life line refers component of your system in this case. You can use collaboration diagram as well but sequence diagram is more powerfull for this purpose.
I would like to make a component diagram for a multiple robot coordination system.
I would like to show on the component diagram that the sub-component "Perception" of each "Robot" component communicates through an interface with each other. Indeed, the sensors of all robots are used in order to estimate the position/velocity of each robot, it is a cooperative sensing.
How can I do that ? Should I have an interface which would be both provided and required by the component "Robot" ?
Thanks.
For this type of system you are in position to use full power of UML and make really effective documentation. You will most likely need some (or all) of the following diagrams:
Component diagram - to show the "big picture" and the main parts of your system ant their interfaces and dependencies. Components are "black boxes" here and will be detailed in the following diagram
Composite structure - are perfect to open up the components and show their internal structure. You can take "black boxes" and their interfaces as kind of input to this work. Each component (except the external ones) should be modelled internally. This kind of diagrams lets you use the whole-part paradigm to model internal structure as a network of interconnected elements. Previously detected interfaces will be used here to show how they are actually implemented.
Class diagrams. If you need to further specify the elements of internal structure (their attributes, methods, associations, etc), this is the diagram to draw.
State machines. In embedded real-time systems, lots of classes are active and have states. Identify those classes (or even components) and use state diagrams to show their internal logic.
Sequences and interactions. These diagrams will help you to specify how different elements of your system work together to implement different scenarios.
Deployment diagram. As robot is a piece of hardware and these components run on it (or them, if there are more than one hardware node) you might want to show how the components are distributed over the hardware structure.
You could also have a look on timing diagram, relativelly new one, designed especially for real-time systems. It might come on handy if you need to express time restrictions, durations, etc.
If you are new to UML, I would recommend to start with components and deployment. They are relativelly easy to learn. As you feel understanding and need to express your ideas further, dive in the composite structure and states. And finally classes.
Have fun!
EXAMPLE
This is how I understand your model and its elements. This extends my comments.
Explanations are in comments and in the diagram notes.
A component diagram:
A component instances' diagram:
Note that the first diagram should be extended with the "connectivity rules" that define all valid connectivity possibilities. Is there only one CentralManager? Must each Robot be connected to CentralManager? Can a Robot talk to itself? And so on...
These and other questions should be modelled separatelly. On class diagrams benavior diagams, according to concrete details.
UML component diagrams are good at showing technical client-server-like inteface relationships between components, using the "lollipop" notation or dependency arrows.
Is there a notation in component diagrams for showing in which direction information flows through interfaces on business process level? Like a client can connect to a server and
put/push information,
get/pull information or
the interface is used bidirectionally.
How can that be depicted in component diagrams?
UML activity diagrams allow for in-flow and out-flow pins, however ommitting the bidirectional case. Would it be sane to use the pin notation on component ports?
Sure can, a high level conceptual line was added to UML at some point. They are called information flows. The direction of the arrow makes sense to business users as well. The OMG spec covers this pretty well. For the push, pull, etc meta data I would use keywords or stereotypes to convey this. Interfaces, Classes, Data Types can all be referenced by the Information flow as what is traveling between the two classifiers (Components, Classes, etc). Many tools have implemented this construct because of it's usefulness despite in being and auxiliary construct.
Link to OMG spec and location: Section 17.2 on printed page 609. Superstructure, ie what you use (http://www.omg.org/cgi-bin/doc?formal/09-02-02)
17.2 InformationFlows
The InformationFlows package provides mechanisms for specifying the exchange of information between entities of a
system at a high level of abstraction. Information flows describe circulation of information in a system in a general
manner. They do not specify the nature of the information (type, initial value), nor the mechanisms by which this
information is conveyed (message passing, signal, common data store, parameter of operation, etc.). They also do not
specify sequences or any control conditions. It is intended that, while modeling in detail, representation and realization
links will be able to specify which model element implements the specified information flow, and how the information
will be conveyed.
The contents of the InformationFlows package is shown in Figure 17.2. The InformationFlows package is one of the
packages of the AuxiliaryConstructs package.