Issue #79 Component and Deployment Diagrams

[cdamus]

Review Notes

This pull request implements an initial prototype of Component and Deployment diagrams for UML Light for further requirements analysis.

Component Diagram

New Metaclasses required

• Component (obviously)
• Port — encapsulation of the port interfaces and messaging through ports is a critical aspect of component-oriented design with UML
• Usage is necessary for derivation of provided interfaces, both on ports and on components. A simple Dependency does not suffice. Note that it is not currently supported in the UML Light Class Diagram

Metaclasses omitted

• Model — models are intended as top-level packages
• Abstraction — this is not supported in the UML Light Class Diagram and we already have the InterfaceRealization and ComponentRealization abstractions, and in UML Light Deployment Diagram the Manifestation, so the more general Abstraction is not needed
• Manifestation does not really belong in the component diagram — it is a deployment concept
• Reception — signals are not currently supported in our UML Light dialect

Assumptions

Components have some limited package-like semantics, being able to collect arbitrary packaged elements in the Component::packagedElement collection (unlike packages, components cannot apply profiles; they are not packages). So, the prototype allows a Component to own a component diagram showing nested components as packaged elements.

This prototype assumes that UML Light would be interested in behaviour modeling for components, so the architecture definition model allows the owned diagrams for Component to include state machine, activity, and sequence diagrams but not use case diagrams.

Open Questions

As components can package elements, they can logically contain classes used in their definition. Should the UML Light tooling allow creation of class diagrams in components? It is not proposed (yet) to support composite structure diagrams for components, so it is not clear what would be the benefit of being able to use a class diagram to model packaged types without that structure.

Deployment Diagram

New Metaclasses required

• Deployment (obviously), DeploymentSpecification, Node, ExecutionEnvironment, Device, CommunicationPath, Artifact, Manifestation are all key deployment concepts

Metaclasses omitted

• Model — models are intended as top-level packages

Assumptions

Components have some limited package-like semantics, being able to collect arbitrary packaged elements in the Component::packagedElement collection (unlike packages, components cannot apply profiles; they are not packages). So, the prototype allows a Component to own a deployment diagram showing deployments of nested components.

This prototype assumes that UML Light is not interested in behaviour modeling for deployment targets (nodes, devices, etc.), so the architecture definition restricts the owned diagrams for DeploymentTarget to exclude state machine, activity, sequence, and use case diagrams.

[planger]

Thanks a lot, Christian! Looks good to me. There is only one or two styling issues which I can take care of. I've provided a test build to Francis, so let's wait for his feedback. If he's fine with this build, we can merge this into a dedicated branch. Thanks!

[cdamus]

Thanks, @planger. I had originally intended this actually to target the components_and_deployments branch instead of master. Now I have fixed that. I think I should also merge master into it now that the branding is updated.

[cdamus]

Great thanks! I already approve it, but we can leave it open to see if Francis has feedback. Thanks again!

Right. I just wanted to be sure that pressing the 'merge' button wouldn't dump this into master!

[cdamus]

@planger Any feedback from the customer? It's a separate branch, so there would be no harm in merging to get this issue off the books, and feedback can be addressed with new issues targeting the branch.