Closed cdamus closed 5 years ago
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!
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.
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!
@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.
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 UMLUsage
is necessary for derivation of provided interfaces, both on ports and on components. A simpleDependency
does not suffice. Note that it is not currently supported in the UML Light Class DiagramMetaclasses omitted
Model
— models are intended as top-level packagesAbstraction
— this is not supported in the UML Light Class Diagram and we already have theInterfaceRealization
andComponentRealization
abstractions, and in UML Light Deployment Diagram theManifestation
, so the more generalAbstraction
is not neededManifestation
does not really belong in the component diagram — it is a deployment conceptReception
— signals are not currently supported in our UML Light dialectAssumptions
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 aComponent
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 conceptsMetaclasses omitted
Model
— models are intended as top-level packagesAssumptions
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 aComponent
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.