Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic TAU (steve huntington)
Decrease font size
Increase font size
Topic Title: Component Diagrams - Ball and Socket Notation
Topic Summary: What's the correct way to show I/F dependencies?
Created On: 23-May-2007 18:01
Status: Read Only
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 23-May-2007 18:01
User is offline View Users Profile Print this message


Graham Mudd

Posts: 9
Joined: 15-Feb-2006

I am trying to make a component diagram showing provided and required interfaces and the dependencies between them. According to the UML 2 resources I have seen on the web, there are a couple of ways to do this; some people show the socket joined to the ball, others show a dependency arrow running from socket to ball. I don't really know what the difference is, but Tau doesn't seem to offer either. All I can do is draw a dependency arrow from one component body to another. Any suggestions? Also, is there any way to resize the box that the signal list goes in? I have a required interface (socket) with 12 dependencies in it - with the fully-qualified names (no way to change that either) it goes off the edge of my sheet.
Report this to a Moderator Report this to a Moderator
 23-May-2007 22:43
User is offline View Users Profile Print this message


jon chard

Posts: 4
Joined: 22-Dec-2004

Hi Graham,

Two options exist in Tau for showing provided and required interfaces on compoenents:
1) You can draw a dependency lines to required interface classes and realization lines (dotted line with closed arrowhead) to provided (realized) interface classes. The realization line is created by dragging the generalization line from the interface to the component.
2) You can use the ball and socket notation in conjunction with ports defined on the components. Note that you must first add a port to the coponent - the direct use of ball and socket notation on a component (or other class) is not supported.

Concerning the presentation of a lengthy signal list, there are a number of options to imporove things:
1) Signals can be defined in an interface class - you then only need to refer to the interface class name.
2) Signals can be collated into a signallist - you can then refer to the signallist name.
3) By defining appropriate dependencies between the packages containing and referencing the signal definitions, you should be able to use unqualified names.
4) You can use CRs between the signals to improve the form factor of the text box.

/Jon
Report this to a Moderator Report this to a Moderator
 24-May-2007 09:14
User is offline View Users Profile Print this message


Graham Mudd

Posts: 9
Joined: 15-Feb-2006

Hi,

Thanks for the reply, but I think I may not have explained the problem well enough (it's difficult without pictures).

I know about classes, interfaces and realisation. I am already using the ball and socket notation thanks, with ports etc., just as you suggested.

The question relates to how I show that a socket is "connected" to a ball. From trawling the internet there seems to be 3 common ways to do it - either:
 
a) Drag the socket over the ball so that they are shown coupled together, or
b) Draw a dashed line with an arrow (a dependency) from socket to ball, or
c) Draw a dependency line from package body to ball

I can't attach a picture to this post, but here's a link to a diagram that shows styles a) and c):

http://www.agilemodeling.com/style/componentDiagram.htm

And here's a link to a diagram showing style b):

http://www.sparxsystems.com.au/resources/uml2_tutorial/uml2_componentdiagram.html

I'm not a UML2 style expert by any means, so I can't say which style is better, but Tau doesn't seem to do any of them.

On your second point -

I already have the signals grouped into interface classes. I have a module which starts up a bunch of parallel applications (12 of them), so it has a dependency on those 12 interface classes.

As it happens, adding carriage returns was the simplest solution for me - I didn't realise you could manually edit the signal list string, as I was trying to drag the control handles on the edit box (they only allow you to move it). I will try adding package dependencies to see if this removes the need for fully-qualified names.

Thanks
Graham

Report this to a Moderator Report this to a Moderator
 24-May-2007 09:56
User is offline View Users Profile Print this message


jon chard

Posts: 4
Joined: 22-Dec-2004

Hi Graham,

Thanks for the further explanation.
At present the only way to connect a ball and socket on a component (class) diagram is to move the component as the ball/socket symbols cannot be resized.
It is possible to show the connection of interfaces on a composite structure diagram using connector lines.

Regards,

/Jon
Report this to a Moderator Report this to a Moderator
 25-May-2007 18:53
User is offline View Users Profile Print this message


Greg Gorman

Posts: 75
Joined: 4-Oct-2002

Looking at the UML Superstructure, the recommended notation is the joined ball-and-socket as far as I can tell. I believe your b) and c) are alternate interpretations (that may be easier to support from a canvas editor perspective) but don't seem to be explicitly allowed by the specification in Table 8.2 (although see the part I copy/paste below, it seems to imply that you can use Realizations between interfaces as well as usage dependencies).

You are right, that today we can't physically connect them, but they are connected logically by the Realized and Required paths.

I'll add this to the requirements database.

Greg

From the superstructure:
Variations

Variations of structure diagrams often focus on particular structural aspects, such as relationships between packages, showing instance specifications, or relationships between classes. There are no strict boundaries between different variations; it is possible to display any element you normally display in a structure diagram in any variation.

The following nodes and edges are typically drawn in a component diagram:
. Component
. Interface
. ComponentRealization, Interface Realization, Usage Dependencies
. Class
. Artifact
. Port

-------------------------
Greg Gorman
Vice President, Product Management
Modeling and Test Products
Telelogic AB
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic TAU forum.
There are currently 1 users logged in.
The most users ever online was 15 on 31-Mar-2008 at 16:22.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.