Are libraries components or artifacts?

[mse]

For the longest of time I thought that a UML component was for a library, since it is something one deploys. However, recently I read in a UML text that artifact is used, and that there is a stereotype <<library>> for it. Now I'm rethinking when to use component, class, and artifact.

Have UML components kind of fallen out of use since there is now SysML and composite structure diagrams? It's still in the standard, but I was wondering if there is some criteria for deciding.

[qwerty]

Look on p 679 of UML 2.5.1


q.

[mse]

The figure on page 679 definitely answers the question on the stereotypes. An artifact then has a stereotype <<Library>>. This means that a library such as libC which is the standard C library would be depicted as an artifact like this:



Now, component, according to the stereotypes is a bit confusing, since there are things like subsystems and entities which range in size and scope. I am comparing this with what is done in the following AUTOSAR UML Modeling Guidelines:

https://www.autosar.org/fileadmin/standards/R21-11/CP/AUTOSAR_TR_BSWUMLModelModelingGuide.pdf

They take the approach that AUTOSAR components are to be modeled as UML Components (see for example Figure 2.1: Example of a module package). They do use artifacts in a consistent way with the standard, header and source files are modeled as artifacts. The component and the interfaces are there. I am okay with that. My last question is, should the classes be nested under the component in EA? The component itself however is never translated into code, so nesting classes doesn't give me header files in the end. If I keep the classes outside the component, I lose the encapsulation unless I move them into separate packages.

For example, if you had a Supplier "S1" and "S2" creating components. Both would develop their components, and realize the interfaces. Supplier S1 might have 1 class in their component realizing everything but Supplier S2 might have a more modular approach and will use 2 classes to implement the component. Nesting these classes into their appropriate components however results in no code generation in EA. The classes have to be under the package itself in order to be visible for code generation.

[qwerty]

I always put the classes in components where appropriate. Since code generation is more of a placebo than a real help I soon gave up with that and let coders handle it more efficiently.

q.

[mse]

Actually I noticed something interesting in how EA generates the code. If you draw a dependency arrow from the class that is nested in the component to the interface which is outside the component, then it is included in the code generation.



It's been a bit difficult with understanding code generation in EA given that there is only one page dedicated to C code generation, but through some experimentation, I was able to get the code to generate. While code generation was not my main focus here, it helped me understand my model a bit. The approach of nesting classes then within the component, and then having those components implement those interfaces looks to me like a good approach where I use the three types of classifiers in a way that works for the AUTOSAR UML guidelines.

• Artifact for the library (for example a .a library that results from linking object files
• Artifact <<source>> for source and header files, and these have relationships <<manifest>> with the library artifact.
• The <<source>> also <<manifest>> the library component
  
• The component has inner classes, and these are the design elements that have the methods and attributes. They implement interfaces of the component.

I can then swap out components as needed.I can change the internals without affecting the rest, as long as the interfaces are stable. I may not model everything like this complete with diagrams and all, but it helped to understand things for this posting:

[qwerty]

Your arrows look strange. Just like from that free UML tool which generates diagrams from text instructions (forgot the name). AFAIR the EA arrows were UML compliant.

q.

[mse]

That was a PlantUML diagram since I can't upload my screenshots from EA without having to signup for some service so I went with the PlantUMl server to draw a sketch of the problem.