Hello
For my software architecture model (for a software system) I want to differentiate between two concepts, i.e. module and component. I use the definitions from the book “Documenting Software Architectures: Views and Beyond”.
The definition of a module is as follows:
An implementation unit of software that provides a coherent set of responsibilities. This refers to “static” view of a software unit, e.g. namespaces or specific directories where the code for a module resides. Modules can be grouped into layers.
The definition of a component is as follows:
The principal computational elements and data stores that execute in a system. This refers to “dynamic” view of software that has been compiled and can be executed. Components can be allocated to tiers.
The relationship between a module and a component is: one or more modules and its functionality can be realized in a component. A component, therefore, inherits all the functions that a module has.
I am having a bit of a problem handling this in Capella/Arcadia. Components exist in the language and most examples that I have seen are more runtime oriented rather than giving a static view of the architecture. There are of course several ways to accomplish this, e.g.:
Have modules as Component RECs. The modules have allocated functions. These modules can be “instantiated” in a runtime architecture model and “allocated” (i.e. be subcomponents of) to a runtime component. By doing this the runtime component inherits the functionality of the module.
Consider components in the Logical Architecture to be modules and make the whole Logical Architecture viewpoint to be the “module view” of the software system. The physical architecture would handle the runtime aspects of the modules defined in the logical architecture.
Implement a new module viewpoint using Capella Studio or extend the current viewpoints to include something called a module. I am not so keen on doing this.
Handle the two different viewpoints parallel in the model. Have the system component split into two subcomponents, i.e. modules and components. The two sections describe the two different views of the system. The functions could be RECs and could be instantiated in both the modules and the components.
Have one software system model that focuses on the runtime aspects of the complete software system. Each component of the software system would have its own model that would describe the module view of that component.
Describe the modules using class diagrams, packages and dependencies.
I would be thankful if someone had some input to these thoughts.
Hello,
Indeed Capella does not natively support the “Module” and “Component” definitions you are working with.
The Component concept in Arcadia/Capella doesn’t refer to the static vs dynamic nature, hence it cannot be directly mapped to the definition you provided. However, the Physical Component concept refers to a component that realizes a behavior, and along with the Deployment concept, they may be useful for you.
You may want to define the layers and the modules (i.e. the static part) in Logical Architecture perspective (cf. fig1) as you proposed in (2).
Then perform a transition to the Physical Architecture perspective and define how the modules are deployed into the components (modeled as Deployed Behavior PC), using the Manage Behavior PCs Deployment tool on the palette (cf. fig2).
This may be enough if modules are deployed in a single component. If multiple deployment is required, then you my want to use REC/RPLs as you proposed in (1).
(3) and (5) seem too complicated. You could do all this work in the PA perspective as proposed in (4) by exploiting the deployment concept, but the use of LA and PA may be useful to handle the complexity of the architecture. I discourage using Class diagrams to describe modules as proposed in (6).
Hope it helps.
Thanks for the answer. It is reassuring to get a second opinion and feel more confident about the direction you are going. I have personally liked the idea of describing the static nature of the architecture on the logical level and the dynamic nature on the physical level. I will proceed with that.
Thanks again.