4

I have a .lib file containing internal C++ classes and a few C++ classes are interfaces to the functionality that software library provides.

How should I illustrate this with UML?

Using Enterprise Architect, I tried type 'Component' (pasted to the component diagram as simple link) and then dragged and dropped the internal classes of that library from the model tree to that component rectangle as element type Composite part, and the interface classes of that library as Port. Now the weird thing is what happened the model tree contains kind of object instances of that classes called Part1 and Port1 of UML type 'class', which is nonsense since a software library don't instantiate, it just provides its classes via .lib file, like a pool. I think UML element type 'component' is not the right thing here, is it? The same happens if I use 'Package', also here parts and ports become things like object instances although classes in a library are not.

falkb
  • 1,294
  • 11
  • 35
  • There's a setting in Sparx EA whereby when you drag and drop to a diagram it will create an instance for you instead of drawing the type. You can change this setting. From memory, something like holding down the CTL key when you drag and drop will open a window where you can choose what happens. – muszeo Dec 03 '18 at 19:04
  • @muszeo: when I drop during d'n'd a dialog gives me a choice for: port/part/neither. I can choose whatever I want, after that the model tree contains an object of that class (as described in my question) and that object creation is wrong IMHO. I just thought I can have the public classes as port, and the inner private helper classes as part. Maybe I don't correctly understand or use the terms 'port' and 'part' when use a component as software library (.lib). Anyway I don't have instances of the classes, the library just provides the classes for use at runtime. – falkb Dec 04 '18 at 09:43
  • 1
    I think I see what you mean. You are wanting to model a logical structure. The Component is a derivative of Classifier in the MOF (as is Class). Perhaps what you want is to use Class modelling semantics to illustrate the interfaces (what you are modelling as ports logically are interfaces) and compositional structure of the component (class structure using e.g. composition). – muszeo Dec 04 '18 at 19:16
  • 1
    The Port is not the interface -- the Port provides an interaction point through which interfaces are provided/required. So your Port should *realise* your interfaces (your interface stereotyped classes), and delegate to internal classes to provide the behaviour. So you would drop your interface class not as a port but as an interface and then have a Port realise it. – muszeo Dec 04 '18 at 19:33
  • @muszeo I asked myself which sense an interface realisation by port makes in the UML-modelling world of software development... Anyway, thanks for your good answers, though I just don't get it what you mean with "compositional structure of the component", maybe you can explain it by a good example from the software development. – falkb Dec 05 '18 at 07:49
  • Sure I'll post as an answer... – muszeo Dec 05 '18 at 23:06

2 Answers2

3

It's not weird. You happened to drop a class as Part (in EA terms).

enter image description here

That's actually a Property. Just open its properties:

enter image description here

See UML 2.5 on p. 147:

9.9.17 Property [Class]

9.9.17.1 Description

A Property is a StructuralFeature. A Property related by ownedAttribute to a Classifier (other than an association) represents an attribute and might also represent an association end. ...

I'd probably just drop them as link to appear as class inside the enlarged component, YMMV

A class dropped as port will show as what the name said. So no confusion here. Anyway, I'd also drop it consistently as link to show just the contents. Further I'd probably stereotype the component itself with <<lib>> or the like. That's because you actually use a lib during compile time to extract the needed parts and it does not work as component by itself. A library though has an interface, namely to extract the compiled class modules it has inside.

Ah, and as @muszeo said: use ctrl-drag to show the above dialog.

Community
  • 1
  • 1
qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • As described in the question the weird thing is the drag'n'drop creates an object of the dragged class and applies that new object as member of the component. This is what I mean with 'nonsense' since I never have an object of a class if a library just provides the class. Furthermore, holding the CTRL-key during d'n'd doesn't change a thing. It still just asks the choice for port/part/neither in my version EA 9.3 – falkb Dec 04 '18 at 09:27
  • 'Property' is not available as option in 9.3 (?) – falkb Dec 04 '18 at 09:33
  • 1
    Yes. 9.3 only supports Port and Part via radio button. Part is equivalent to Property in the drop down of later EA versions (not sure when that actually changed, since I dropped all other EA installations after a fresh Windoze install yesterday). To create a link drop it on a blank space first and drag it over then. – qwerty_so Dec 05 '18 at 12:36
3

Following my comment to the O/P, I'd do something like the below. Please note that I'd probably not depict all of this on the same diagram, the class content of the package for example I might present on a separate diagram so that this is not so cluttered. But the logic is the same.

enter image description here

Update: Following commentary below I've added the this diagram which illustrates an alternative way of representing this. I think in some cases I've seen the delegation represented as a dependency rather than a reference association too. But hey ho. Internally, components are represented as interacting between each other via required/provided interfaces (though this is not shown as in the model below we only have one internal component illustrated).

enter image description here

muszeo
  • 2,312
  • 9
  • 13
  • You should use a delegate relation from SecurePort to a port on CalculationEngine instead. – qwerty_so Dec 06 '18 at 00:41
  • Yes, actually I think you're correct in the context of a composing component port delegating to an internal component, though I have seen it done both ways. I've added a second image for comparison. – muszeo Dec 06 '18 at 01:43
  • I think the correct way is to delegate port->port, not port->interface. At least, that's what I'm doing generally. – qwerty_so Dec 06 '18 at 07:56
  • This is really a good illustration. Questions remain: What is the UML element type of circle ICalculationStrategy and ICalculationEngine (I don't have such circle thingy in EA 9.3)? Is ICalculationStrategy a C++ class public to the outside world of the DLL? Are CalculationStrategyFactory, CalculationStrategy and OffPeakCalculationStrategy are internal helper C++ classes within the DLL or are these objects? What is the UML element type of that MyCalculationLibrary.dll box, is it an UML element type class or object? – falkb Dec 06 '18 at 11:01
  • 1
    hey, the circles are a shorthand notation in UML for <>stereotype classes. In Java or C# this would be declared using the interface keyword, in C++ the closest to this would be an abstract class with all methods being pure virtual and with no attributes. Interfaces are, logically, a behaviour contract. All the classes in the package are manifest within the dll, which I've modelled as a stereotyped artifact here. There are no objects shown, which would be rectangles with underline in their name and a name/type specification being a colon. – muszeo Dec 06 '18 at 18:17
  • @ThomasKilian yes I've seen that way as well! TBH I'm not 100% clear on the correct way, looking at my training materials from way back when I notice they use port—>interface i.e. example #2 above. I’ve never tried to script the generation of code off this sort of model, maybe if I did it would become clearer. e.g. ports, bindings and interfaces is WSDL should have a corresponding representation that works best in UML. Edit: Training notes are from IBM. – muszeo Dec 06 '18 at 18:23
  • I'm not sure either. Port->port is what I used in a large project where it worked well. If you split responsibility of different interfaces of a port you'd use port->interface. I did not have that case though it was a really large project with many ports/interfaces. – qwerty_so Dec 06 '18 at 21:08
  • @falkb The circles are named lollipop notation. They go along with the sockets. The lollipop is a provided interfaces (yummy) and the socket is a required one (like a hungry mouth that needs to be fed by the lolly). – qwerty_so Dec 06 '18 at 21:12
  • @muszeo Which UML element did you use for the .dll box? – falkb Dec 07 '18 at 07:27
  • It seems to me components are for bringing artifacts, objects, devices, classes and packages together, things of classifying stuff and real world objects together in one logical unit, right? – falkb Dec 07 '18 at 10:32
  • Yes that's about right. The UML 2.5 spec, section 11.6, describes a component as a "modular unit with well-defined Interfaces that is replaceable within its environment". The key thing is that a component has defined interfaces, is self-contained and substitutable. Self-contained doesn't mean it can't use libraries or call out to other components, just that it encapsulates its behaviour and data (like a class). – muszeo Dec 09 '18 at 02:17