The goal of a component diagram is not the same than a class diagram. Nor is it an alternative to package diagrams.
The focus of component diagrams is on self-standing, replaceable components, and how these can be assembled to make more complex systems.
1) The ball/socket representation is about interfaces provided/required. So FooImpl would be a ...
Some additional thoughts beyond Albuquerque's answer, which I fully support:
Drafting an SRS is one way to capture the requirements. Unfortunately it requires to think about all the requirements upfront, at a moment the analyst may not have a full understanding of the domain, and the user don't yet get what the system can/will do for him/her nor what the ...
YOUR TEAM must know what is good for YOUR TEAM
The amount of detail the user tasks should have are team dependent. In that sense, it is not possible to know if for YOUR TEAM it will be good to attach such artifacts or not.
For teams that are starting to get used to working with user stories, having to always attach artifacts to stories would just create ...
Rather than swim lanes (which are purely graphical annotations) you would use Partitions which are concrete UML elements. You can classify these partitions (e.g. with components representing the environment in question).
Further I suggest to use Pins and an ObjectFlow where objects (like the YAML) are sent along actions.
Yes and no !
Yes you can model it !
The UML activity diagram models control flow and object flow. Both are very practical to model individual functions, function composition and function pipelines:
Functions would be represented by actions.
Composition can be shown with activitiy edges, if needed using pins to show that object flows from the ...