Code generaton and design issues

[Dan]

Hi all,

I've had BOUML for a few weeks and I believe that only a package with a class view / diagram / class can generate (or round trip) code. The project package and sub package options for headers and source directories and name space are very useful and seem to work as expected.

Q: Are there any other diagrams / views etc that are able to generate code ?

I want to use BOUML to assist me in designing some features of a small project (it's a simple game using my own game engine) and I would like to use the component views / diagrams in my design /code.

But I do not really understand BOUML component / component diagrams as although one can set required class, provided class and realising class (from a list of existing classes) - I can see no way to use this is in a design as there appears to be no generated code or class 'interfaces' or anything at all.

Also I cannot drag components onto any other diagram, so they cannot be used to explore part of a design.

Q: Are BOUML components only a visual elements?

Q: Does adding a 'provided interface' to a component have any code generation effects?

Thanks.

[Bruno Pagès]

Hello,

I've had BOUML for a few weeks and I believe that only a package with a class view / diagram / class can generate (or round trip) code. The project package and sub package options for headers and source directories and name space are very useful and seem to work as expected.

Q: Are there any other diagrams / views etc that are able to generate code ?

In the model a file (or a couple header/source files for C++) is supported by an artifact, so the generation/roundtrip works on the artifacts. When you start the code generation/roundtrip from an upper level they go down searching for artifacts. The diagrams are out of the code generation/roundtrip.

By definition an artifact is about deployment, so you can put artifacts only in deployment views, and to start code generation/roundtrip in an other kind of view as no sense, except that to help I also allow to start from a class or a class view but in that case the work is done for artifacts associated to the classes, this is a shortcut if I can say.

I want to use BOUML to assist me in designing some features of a small project (it's a simple game using my own game engine) and I would like to use the component views / diagrams in my design /code.

But I do not really understand BOUML component / component diagrams as although one can set required class, provided class and realising class (from a list of existing classes) - I can see no way to use this is in a design as there appears to be no generated code or class 'interfaces' or anything at all.

In UML 2.x the components are not part of the deployment, so they cannot participate to the generation/roundtrip, nor a use case for instance.

In the old versions of UML there was no artifact and the tools used components for the code generation (including BoUML before the release 2.0) , but since the artifacts was introduced the roles was changed and clarified.

Anyway even the components are at a conceptual level this doesn't mean they are useless, I encourage you to use them. In the past I found a very interesting paper about the components, unfortunately I lost its reference and cannot find it again with a quick search.

Also I cannot drag components onto any other diagram, so they cannot be used to explore part of a design.

No, you can also drop a component into a deployment diagram, or use the associated button in a deployment diagram to choose one to insert into the diagram.

Q: Are BOUML components only a visual elements?

No, the model is not only the diagrams, a component exists by itself, even it is not drawn into a diagram.

Q: Does adding a 'provided interface' to a component have any code generation effects?

The components are out of the code generation, so no effect.

[Dan]

Thanks for the extensive reply - I understood most of it, so maybe I am getting the hand of BOUML ...

So if I wanted to indicate in my 'design' that there are 'components' (which I would think of a grouping of classes), I could use a class inside a package / name space that would act as the 'component interface'.

Thanks.

[Bruno Pagès]

...which I would think of a grouping of classes

This is not what a component is, the most important word about them is the word replaceable, and because of that what they need and what they provide is defined through interfaces rather than basic classes

[Dan]

Hi,

I know that a lot of UML has nothing to do with code generation - but my posts are focused on what BOUML features CAN generate code and how I could use that in a current project.

Now in C++ (as you will know) there is no such thing as a 'component' as such, basically there are just classes and we design / name them as we will. For instance a class can be designed as an 'abstract interface' (defining a set of methods), so concrete classes can provide these methods. I will not even start on design patterns - let them sleep!

So my posted comment was about how the concept of a UML component could be seen as a class interface (maybe in a package / name space).

Below is a comment from https://www.uml-diagrams.org/component.html

>>
A component is a class representing a modular part of a system
with encapsulated content and whose manifestation is replaceable within its environment.
A component has its behavior defined in terms of provided interfaces and
required interfaces (potentially exposed via ports).
<<

So they indicate a component is defined by an interface - which I will take as a class interface, as there is not much else it could be in C++.

It is a shame that the nice visual presentation of the UML component cannot be placed onto a BOUML class diagram - at least then it would be useful.

My issue with UML is it is can be difficult to understand from a programmers perspective. I am sure designers love it ... but programmers not so much ...

Thanks.

[Bruno Pagès]

Dan,

I know that a lot of UML has nothing to do with code generation - but my posts are focused on what BOUML features CAN generate code and how I could use that in a current project.

We are on the same wavelength, I made BoUML not only to do UML, but also for code generation, this why I added dedicated aliens for UML point of view (for instance extra members), and I allow users to specify precisely what have to be generated throw textual forms containing keywords.

So my posted comment was about how the concept of a UML component could be seen as a class interface.

For me to try to do that is an error, in UML components are something else.

...
So they indicate a component is defined by an interface - which I will take as a class interface, as there is not much else it could be in C++.

The signature of a component is defined through required/provided interfaces, but this doesn't mean a component is an interface

It is a shame that the nice visual presentation of the UML component cannot be placed onto a BOUML class diagram - at least then it would be useful.

May be I make BoUML too strict, but or me class and component are not at the same level.

A class stereotyped <<interface>> has by default a dedicated representation into the class diagrams, you don't like it ? Furthermore the name of a class declared abstract (through the corresponding check box in the class editor) is written in italic in the diagrams. So it is easy to differentiate them from standard classes info class diagrams. After if you want to group them in the diagram you can use a package or a combined fragment

Anyway, through stereotypes part of profiles you can indicate the icon you want to see in the diagram at the place of the standard representation of the stereotyped element, so you can ask for to see a component in class diagrams for the classes having a given stereotype.

My issue with UML is it is can be difficult to understand from a programmers perspective. I am sure designers love it ... but programmers not so much ...

[Dan]

Thanks for that.

A class stereotyped <<interface>> has by default a dedicated representation into the class diagrams, you don't like it ? Furthermore the name of a class declared abstract (through the corresponding check box in the class editor) is written in italic in the diagrams. So it is easy to differentiate them from standard classes info class diagrams. After if you want to group them in the diagram you can use a package or a combined fragment

OMG - I've now going to have to see what a "a combined fragment" is ...

Anyway, through stereotypes part of profiles you can indicate the icon you want to see in the diagram at the place of the standard representation of the stereotyped element, so you can ask for to see a component in class diagrams for the classes having a given stereotype.

Again not sure how this works - would be nice to have some more 'icons' ... I'll look into it ...

Thanks.

[Bruno Pagès]

OMG - I've now going to have to see what a "a combined fragment" is ...

There are a lot of things in UML, if that can comfort you note that I also had to know them and understand them ... but in addition to add them in BoUML

... would be nice to have some more 'icons'

Where would be the pleasure if you had nothing to do

P.S. Currently I had class composite diagrams in BoUML, this is a big work