Python design mode-UML-component diagram (Component Diagram)

Brief introduction

Component diagrams, also known as building diagrams, are used to display physical views of the system's components and the relationship of each component.

Component diagrams typically include components, interfaces, relationships, ports, and connectors to display dependencies and generalization relationships between corresponding modules, source files, or collections of source files in program code.

Components in a component diagram are typically implemented by one or more classes (objects) in a class diagram as modules, source files, process files, or executables in the system, ultimately constituting the majority of the system's functional units.

Component Diagram Modeling steps

-Determine what external interfaces or ports the system has

-Determine which components are used by the system, identify important modules in the system, library files, source code files, data tables or files, executables, or documents, and model them as components

-Determine the types, specifications, constraints, and internal interfaces of each component in the system

-Determine the relationship between components in the system, between interfaces, and between components and interfaces

Elements of a component diagram

Elements in a component diagram include components, interfaces, relationships, ports, and connectors, where there is a dependency between the component and the component, and there is an implementation relationship between the component and the interface.

• Components : The actual files that assume the specific function units, usually lib, jar, DLL, EXE and other formats, follow the interface definition and provide specific interface implementation
  

　　　　　　　-Component notation

-Icon notation

Icon Representation Small icon notation

　　

-Construction notation

　　　　　　　　　　

　　　　

　　　　　　　-Component classification:

-Configuration component: The Environment profile for each component in the system when it executes

-Product components: Static source files before system operation, including modules, source code files, source data files, link library files, executable files, etc.

-Process components: components generated by the system runtime, including dynamically generated class files, new data files, log files, dynamic Web pages, etc.

• interface : A set of operations that declares a service contract provided or requested by a component that is implemented and used by components that implement and use this interface.

The interface can be divided into requirements interfaces and interfaces from the invocation dependency angle.

　　　　　　-Requirements Interface: Also called Required interface, which is the interface to be followed when the component requests services like other components

　　　　　　-Provides interfaces: Also known as interfaces, which are features and constraints implemented when components provide services to other components

　　　　　　

• Relationship: Implementation, dependency, generalization (see The Relationship section of the component diagram in detail)

• Port : belongs to the external interface and is the interaction point between the encapsulated component and the outside world. Components that implement interfaces use ports to send and receive messages, interacting with the outside world

　　　　　　-notation: Represented as small squares in UML2.0

　　　　　　　　

　　　　　　-Interface Relationship: The demand interface requests the service from the outside through the port, providing the interface to the external service through the port

　　　　　　-Component relationships: components can interact with each other through ports, such as sending and receiving messages

• connector : A communication relationship between two components or two ports. UML2.0 offers two types of connectors

　　　　　　-Proxy connector : connector between external port (port) and internal interface

　　　　　　-assembly Connectors : connectors between components. The connector establishes a connection between the requirements interface of one component and the provider interface of another component, enabling the previous component to invoke the services provided by the latter component

　　　　　　　　

Relationship of component diagrams

The relationships in a component diagram are implemented, dependent, and generalized, mainly involving components and components, between components and interfaces, and between interfaces and interfaces.

• implementation : The relationship between a component and an interface

• dependencies : The relationship between components and components

If there is a dependency on two classes in two components, the relationship between the two components can be expressed as a dependency relationship

• generalization : between components and components, between interfaces and interfaces

If there is a generalization relationship between two classes in two components or two interfaces, the relationship between the two components can be expressed as a generalization relationship

Component Diagram example

Taking the bank short message customer service system as an example

The difference between component diagram and similar UML diagram

• component diagrams differ from class diagrams : Component diagrams differ significantly from class diagrams in the following ways

　　　　　　-level of abstraction : Class diagrams focus on abstraction of individual entities and detail logic; component diagrams focus on abstraction of modularity and deployment implementations

　　　　　　-Abstract granularity : classes, interfaces, and their relationships are granular in class diagrams; component diagrams are granular in function units, usually consisting of several classes or interfaces

　　　　　　-External invocation : When a class in a class diagram is called externally, its properties and actions can be called directly based on its visibility, and the components in the external call component diagram are accessible only through the interface

　　　　　　-Deployable : The class diagram corresponds to a single entity and logic, the organizational structure is more decentralized and not deployable; the components in the component diagram are themselves modular, near-final functional units, and are deployable

• component diagram and package diagram differences : Component Diagrams and package diagrams have significant differences in the following areas

　　　　　　-level of Abstraction : Package diagrams focus on the container abstraction of classes, interfaces, and packages; component diagrams focus on modular abstraction of library files, source code files, executables, and more

　　　　　　-Organizational Structure : Package diagrams focus on static, no-change file structures; component diagrams focus on dynamic, file structures that change with the compile/link/execute Process

　　　　　　- Deployable: Package diagrams focus on organizational relationships and hierarchies between source files, are not deployable, and the components in the component diagram themselves are dynamic executables, so they can be deployed

　　　　　　- element Relationships : The relationships between package diagram elements are mostly static inclusions or associations; the relationships between component diagram elements are mostly dynamic calls or implementations

Considerations for Component diagrams

-Component size is moderate, easy to analyze and not too large

-The element relationship in the component diagram needs to be relative to the relationship between the class diagram and the element in the package diagram, avoiding inconsistencies and ambiguity.

-element nouns and source files in a component diagram always, consistent with elements in the deployment diagram

-Component diagram If it is too complicated and has to mark the whole component, it can be split into the General Assembly diagram and several component sub-diagrams properly.

Python design mode-UML-component diagram (Component Diagram)