The main advantages of using this Component Model are as follows:<\/p>\n\n\n\n
- \n
- It is easy to create and understand the system architectures, as all of them are using the same decomposition approach for modeling the internal structure<\/li>\n\n\n\n
- It is easy to identify the integration points, as all the provided and required application services (or -interfaces) are defined<\/li>\n\n\n\n
- The whole EA of an organization is becoming more coherent and consistent, as each individual system is depicted with a common modeling style.<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2024\/01\/image-2.png\")
Figure<\/strong>: Component Model depicts the target application on different abstraction levels.<\/figcaption><\/figure>\n\n\n\n Abstraction levels are as follows:<\/p>\n\n\n\n
- \n
- At CM-<\/strong>1 -level (Context) the diagram describes how the application interacts with its environment, and what are the interactions with adjacent applications and users. The target application is depicted as a black box. <\/em>This is the “EA-level”: the internal structure of an application is not relevant, only the services exposed.<\/li>\n\n\n\n
- At CM-<\/strong>2 -level (Composition) the diagram describes how the target application is decomposed into modules (main components), and what application services (or application interfaces) those modules provide and require (use). The logical decomposition of an application is based on the functional aspects, which typically relate to physical decomposition too. The target application is depicted as a white box<\/i>. This is the internal structure of an application.<\/li>\n\n\n\n
- At CM-<\/strong>3 -level (Component), these diagrams describe how the main modules are decomposed into sub-components, and what are their responsibilities (internal functions or processes), what are the services or interfaces that these components provide and require (use).<\/li>\n<\/ul>\n\n\n\n
The Application Component Model (CM) diagrams below consist of application components and application services. Alternatively, application interfaces can be used instead of application services depending on the case. As always, it is important to utilize such a modeling style that is appropriate for the purpose, and model only those elements that are informative enough and provide certain added value. It is up to the modeler, whether he or she likes to emphasize the functional aspects, or to be more concrete, and model e.g. the actual interfaces with exact naming.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2024\/01\/image-1.png\")
Figure<\/strong>: Abstraction levels of the Component Model.<\/figcaption><\/figure>\n\n\n\n Component Model – 1 (CM-1) – Context<\/h4>\n\n\n\n
Component Model – 1 (CM-1) level illustrates interactions between the target application and adjacent applications. All the relevant application services are introduced. The 1-level diagram consists of enterprise architecture-level components and their services, the target application is in the middle.<\/p>\n\n\n
\n![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2023\/05\/image-4.png\")
Figure<\/strong>: Component Model level – 1.<\/figcaption><\/figure>\n<\/div>\n\n\n An additional information flow diagram can be provided on the Component Model level – 1. An information flow diagram (a.k.a application cooperation- or application interaction diagram) makes it visible how the data is switched between the applications: from where the business relevant data is transferred to which direction. <\/p>\n\n\n
\n![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2023\/05\/image-8.png\")
Figure<\/strong>: Component Model level – 0 information flows.<\/figcaption><\/figure>\n<\/div>\n\n\n Note! For more detailed integration description can be illustrated on Component Level – 2, where it is explicitly defined which application actually starts the interaction – with more detailed information about the mechanism (e.g. synchronous\/asynchronous), protocol (e.g. FTP, rest) etc. when appropriate.<\/p>\n\n\n\n
Application Component Model – 2 (CM-2) – Composition<\/h4>\n\n\n\n
Component Model – 2 (CM-2) level illustrates how the target application is decomposed into modules (or main components), and which module realizes which application interfaces. Note! External applications can be left out from this level, but their interfaces are shown. Provided<\/em> interfaces are colored with the default color (turquoise blue), and required<\/em> interfaces are colored grey. <\/p>\n\n\n
- At CM-<\/strong>2 -level (Composition) the diagram describes how the target application is decomposed into modules (main components), and what application services (or application interfaces) those modules provide and require (use). The logical decomposition of an application is based on the functional aspects, which typically relate to physical decomposition too. The target application is depicted as a white box<\/i>. This is the internal structure of an application.<\/li>\n\n\n\n
- At CM-<\/strong>1 -level (Context) the diagram describes how the application interacts with its environment, and what are the interactions with adjacent applications and users. The target application is depicted as a black box. <\/em>This is the “EA-level”: the internal structure of an application is not relevant, only the services exposed.<\/li>\n\n\n\n
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2023\/05\/image-6.png\")
![\"\"](\"https:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2023\/05\/image-7.png\")