CN117130603A - System model analysis and storage method - Google Patents

Abstract

The application relates to a system model analysis and storage method, belongs to the technical field of model drive development, and solves the defects in the analysis and storage processes of the prior art. The system model analysis and storage method comprises the following steps: obtaining an xml file of the system model; analyzing the content of the element to be analyzed in the xml file of the system model; storing the parsed element content into a database, and constructing the relation among the elements; the element to be analyzed is an element which is determined according to the meaning of the element name in the meta-model and corresponds to the meaning.

Description

System model analysis and storage method

Technical Field

The application relates to the technical field of model drive development, in particular to a system model analysis and storage method.

Background

The application is based on the Web (world wide Web) or B/S (browser/server) architecture, and in the society with the rapid expansion of information, human beings are entering a brand new era, namely the information era. One notable feature of the information age is the use of computer networks. The computer network is developed into the most popular Browser/Server computing mode at present through the Client/Server stage (comprising two layers of C/S and three layers of C/S), and a Browser-Server (Browser/Server) structure, which is abbreviated as a B/S structure, is different from the C/S structure, and a Client does not need to install special software, only needs to be a Browser, and the Browser interacts with a database through a Web Server, so that the computer network can conveniently work under different platforms; the server side can adopt a high-performance computer and install a large database such as mysql. The B/S structure simplifies the work of the client, which is generated along with the rise of the Internet technology and improves the C/S technology, but the work of the server side under the structure is heavier, and the performance requirement of the server is higher.

Model driven development Model Driven Development (MDD) is a development method of high level abstractions with models as the main artifacts, which are transformed into data stored in a structured database as core assets with the support of the present application. Over the past years, software development has faced a number of challenges, new needs and existing systems have grown, and systems have become more and more complex, so that it is difficult to build them in time. In order to solve these problems, many new methods have emerged, one of the most prominent being model driven development. MDD represents a set of theoretical and industrial software development methodologies framework, the use model of the system as the main workpiece in the whole life cycle of software development, which is mainly aimed at solving two fundamental crisis of software: complexity and change capability, using the model as a document and specification is valuable, but it requires strict management to ensure that the model is continuously updated. In practice, we are forced to time pressure often to implement inconsistent models, which is actually detrimental to development and projects. The basic idea of MDD is to let the development center transfer from programming to high-level abstraction, convert the data into structured data through a model, and further develop by using mature database operation.

In the model driven development process, common modeling languages include SysML, AADL, simulink, etc., but no scheme for xml file analysis and element storage for models constructed by the three languages exists in the prior art. In practice, the parsing of xml files and the storage of elements therein have important significance for better cognizing models and using models, so that it is necessary to develop a system model parsing and storing method to solve the above-mentioned problems.

Disclosure of Invention

In view of the above, the present application is directed to a system model parsing and storing method, which is used to solve the above-mentioned drawbacks of the existing system model parsing and storing method.

The aim of the application is mainly realized by the following technical scheme:

a system model parsing and storing method, the method comprising the steps of:

obtaining an xml file of the system model;

analyzing the content of the element to be analyzed in the xml file of the system model;

storing the parsed element content into a database, and constructing the relation among the elements;

the element to be analyzed is an element which is determined according to the meaning of the element name in the meta-model and corresponds to the meaning.

Based on the scheme, the application also makes the following improvements:

further, the parsing the content of the element to be parsed in the xml file of the system model includes:

determining an element path of the element to be analyzed, acquiring the element to be analyzed based on the element path to be analyzed, and analyzing the element to be analyzed to obtain the content of the element to be analyzed.

Further, the modeling language of the system model is at least one of aadl, sysml, simulink.

Further, when the modeling language of the system model is aadl, the xml file of the system model at least comprises an overall architecture; at this time, the parsing the content of the element to be parsed in the xml file of the system model includes:

sequentially analyzing components, link points, communication channels and states of the xml file of the system model; the assembly includes at least system, device, bus.

Further, when the xml file of the system model further includes an error library, the parsing the content of the element to be parsed in the xml file of the system model further includes:

after the state analysis, the xml file of the system model is sequentially subjected to Process analysis, thread analysis, acceptance analysis, transition analysis and Event analysis.

Further, when the modeling language of the system model is symml, the parsing the content of the element to be parsed in the xml file of the system model includes:

simultaneously analyzing the components and exception, linkpoint, task, thread, dataobject; the assembly includes at least system, device, bus;

communication channel analysis was also performed.

Further, when the modeling language of the system model is simulink, the parsing the content of the element to be parsed in the xml file of the system model includes:

when analyzing the component, analyzing linkpoint, state, transition in the component; the assembly includes at least system, device, bus;

when the link point is analyzed, the corresponding dataobject is also analyzed;

when the state is analyzed, the internal transition is also analyzed;

in the analysis of the transition, the relationship between the component and the transition is also analyzed;

communication channel analysis was also performed.

Further, based on the association relation among the elements acquired in the analysis process, constructing the relation among the elements;

wherein the association relationship is at least a parent-child relationship, a reference relationship or an inheritance relationship.

Further, the method further comprises:

and extracting the elements in the database, reorganizing the elements according to an xml format, and generating a meta-model description file in the xml format.

Further, the meta-model includes at least one or more of the following:

Component、Linkpoint、Connection、Class、Interface、Property、State、Transition、Condition、Action、Flow、Event、Input、Output、Message、Constraint、Fault、Failure。

the beneficial effects of the application are as follows:

the system model analysis and storage method disclosed by the application provides the analysis of the xml file and the storage mode of elements in the xml file, thereby facilitating the related technicians to better recognize the model and use the model;

meanwhile, the application provides a scheme for carrying out xml file analysis and element storage on the model constructed by the three languages based on a modeling language (SysML, AADL, simulink) commonly used in the model driving development process;

in addition, the method can also extract elements in the database, reorganize the elements according to an xml format, and generate a meta-model description file in the xml format so as to better analyze a system model.

In the application, the technical schemes can be mutually combined to realize more preferable combination schemes. Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the application. The objectives and other advantages of the application will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

The drawings are only for purposes of illustrating particular embodiments and are not to be construed as limiting the application, like reference numerals being used to refer to like parts throughout the several views.

FIG. 1 is a flow chart of a system model parsing and storing method disclosed in an embodiment of the application;

FIG. 2 is a sequence chart illustrating the parsing process when the programming language disclosed in the embodiment of the present application is AADL;

FIG. 3 is a diagram of analysis logic for connection when the programming language disclosed in the embodiment of the present application is AADL;

FIG. 4 is a sequence chart illustrating a parsing process when the programming language disclosed in the embodiment of the present application is syml;

FIG. 5 is a sequence chart illustrating a parsing process when the programming language disclosed in the embodiment of the present application is Simulink;

FIG. 6 is a schematic diagram of three components represented in AADL disclosed in an embodiment of the application;

FIG. 7 is a schematic diagram of the kf. Before system in the case of the present application;

FIG. 8 is a schematic diagram of an extraction result according to an embodiment of the present application;

FIG. 9 is a schematic diagram of the results of the Rtos table disclosed in the examples of the present application;

FIG. 10 is a schematic diagram of Device results according to an embodiment of the present application;

FIG. 11 is a schematic diagram of a LinkPoint table storage result according to an embodiment of the present application;

FIG. 12 is a schematic diagram of a program table storing results according to an embodiment of the present application;

FIG. 13 is a diagram of a Require table result according to an embodiment of the application;

fig. 14 is a schematic diagram of a result of the communication channel extraction disclosed in the embodiment of the present application.

Detailed Description

The following detailed description of preferred embodiments of the application is made in connection with the accompanying drawings, which form a part hereof, and together with the description of the embodiments of the application, are used to explain the principles of the application and are not intended to limit the scope of the application.

The application discloses a system model analyzing and storing method, which comprises the following steps:

step S1: obtaining xml files of a system architecture model, a demand model and a design model;

the system architecture model is constructed by an acetate, the corresponding programming language is AADL, and the corresponding file suffix in the xml format is aaxl2;

the demand model is constructed by papyrus, the corresponding programming language is syml, and the corresponding file suffix in xml format is uml;

the xml of the design model needs to be exported in matlab through script, and the corresponding programming language is simulink;

the three models should provide at least one. When the programming language is AADL, the corresponding xml file at least contains a total architecture file and can also contain an error library file; wherein the overall architecture file describes the overall of the current system, including which subsystems are unique; the error library file defines the type of error in the system. When the programming language is symml or simulink, only one model file needs to be loaded.

Step S2: analyzing the content of elements to be analyzed in an xml file according to a certain sequence according to an xml structure which is analyzed in advance;

the element to be analyzed is an element which is determined according to the meaning of the element name in the meta-model and corresponds to the meaning. This correspondence can be obtained with reference to table 1 in the embodiment; for example, there is an element name "Component" in the meta model, and according to the meaning of the element name, it can be determined that when the modeling language is AADL, the element corresponding to the element name includes at least three elements to be parsed "Component, thread, process".

The analysis process of the programming language AADL is as follows:

1. due to the existence of foreign key constraints, aadl's resolution needs to guarantee a resolution order, which is shown in fig. 2:

1.1 resolution of components:

the components refer to sub-components of the overall architecture such as system, device, bus and the like, the element paths in aaxl2 are// ownedpublic section/ownedcs hierarchy. N (n is the actual path number in xml), and the three components are classified and analyzed due to the characteristics of the properties of the three components, but the components are used as the generalization types of the components, and are not only inserted into the specific corresponding tables, but also are used as the generalized component tables to be inserted with corresponding data;

in addition, since it is convenient to acquire the id while analyzing the component, the port analysis and state analysis are called here.

1.2 Port resolution

The element in aaxl2 is// ownedpublic section/ownedcs lassifier [ @ name= '"+componet name+"' ]/ownedDataPort, where the first Name is the Name of the upper component, and the last element may be ownedBusAccess, ownedEventPort.

Because the port types supported by different upper elements are different, classification analysis is also performed according to the component types.

For both devices and buses, he supports three linkpoint types, dataport, eventport, and bus access.

1.3 resolution of connections

The corresponding element path is

/(ownedPublicSection/ownedcs lassifier @ xsi: type = 'aadl2: system implementation' ]/ownedPortConnection or

//ownedPublicSection/ownedClassifier[@xsi:type＝'aadl2:SystemImplementation']/ownedAccessConnection

This part of the functionality is relatively independent without parsing other elements, but for a communication channel it has both source and dest ports, whereas in aaxl2 the context attribute represents the upper element pointing to a port and the connection end represents the path of the port, the logic here being shown in fig. 3.

Whereas for a sync type connection there is no context defaulting to the current component.

1.4 resolution of State

The element path is

The// ownedanannexSubclause/paramideAnxSubclause/states/conditions/operants/qualifidedState/state, also considered here, is the need to parse state information in behavir in the error library if aadl uses externally defined errors here.

1.5Process resolution

The task in the corresponding meta-model needs to analyze not only the element as the task, but also the port and the connection below the task, and also the thread below the task.

1.6 resolution of Thread

Is the task in the meta-model corresponding to the child element of the process, and the parsing process is basically consistent with the process.

1.7 resolution of Exception

The analysis path is

The method is characterized in that the method comprises the steps of// ownedcdcsiffier @ xsi:type= 'aadl2:systemtype' ]/ownedanannexsubsubclone/parthenxsubsubclone/usebehavir, wherein the method needs to analyze the production and event together, if the production element has a direction attribute, the following method also needs to have a feature PP element, and the communication channel capable of transmitting faults is analyzed according to source and dest information provided by the feature element.

1.8 Resolution of transitions

The resolved path is// paramedicAnnnexLibrary/behavir [ @ name = '"+behavir name +"' ]/transitions/, the path of event as a trigger is the following condition/qualitafiederPropagationreference/emv 2Target, and the two relationship tables transitionstate, componenttransition are resolved here.

1.9 resolution of Event

The resolved path is in the error library file

The path is// ownedlndex subsubclone/paramedinenxsubsubclone/events when defined in the system internal structure file.

The parsing process of the programming language sysma is as follows, and the parsing schematic diagram is shown in fig. 4:

2.1 resolution of Components

Here, the task and thread are parsed simultaneously exception, linkpoint, task, thread, corresponding Linkpoint, exception is parsed internally, and corresponding dataobject is parsed when Linkpoint is parsed, which are mapped by type attribute in the syspl.

Their analytical paths are as follows:

Component:

//packagedElement[@xmi:type＝'uml:Class']/nestedClassifier[@xmi:type＝'uml:Class'or@xmi:type＝'uml:Device']

Linkpoint:/ownedAttribute[@xmi:type＝'uml:Port']

Task:/nestedClassifier

Exception:ownedRule

Dataobject:nestedClassifier

2.2 resolution of connections

The parse path is// packagedElement [ @ xmi:type= 'uml: informationFlow' ], the syml does not classify the connection, is uniformly processed by the sync type, and source (informationSource), dest (informationTarget) of the connection may not exist for the syml

The parsing process of the programming language for simulink is as follows, and the parsing schematic diagram is shown in fig. 5:

3.1 resolution of components:

when the component is analyzed, the link point, state and transition in the component are analyzed; when the linkpoint is analyzed, the corresponding dataobject is also analyzed; when the state is analyzed, the internal transition is analyzed together; in resolving the transition, the relationship between the component and the transition is resolved together.

In xml, the subsystem corresponds to a < block > tag, the attributes of the module are denoted below by < p >,

block type attribute: subsystem means that the module is a subsystem, and the inport/outport means Port: port number (note: port number 1 does not change the attribute, needs to add the attribute when extracting information), port number is used in < Line > label, find two ports of Line connection through port number and subsystem name that port locates;

description attribute: some attribute of the subsystem, such as wcet, etc.;

the data corresponds to a < data > tag, and the following < p > represents the module attribute, and the following attributes need to be extracted:

dataType: data type.

The data searching method corresponding to the port comprises the following steps: find port operator_feedback for operator interface blocks in < block >, then find operator interface blocks in < chart >, named operator_feedback data.

3.2 resolution of the connection:

the corresponding label is < Line >, the Line label inside the block is not required to be extracted, the Line label which is the same as the block is mainly extracted, in the Line element, a source subsystem is found by the srcBlock attribute, and the srcPort represents the number of the export of the source subsystem; the dstPort attribute finds the destination subsystem and dstPort represents the inport number of the destination subsystem.

Step S3: the parsed elements are put into a library and the relation among the elements is built; preferably, relationships between elements may be constructed from generalized relationships between elements.

To avoid key collisions, conflicting fields or table names are preceded by "_":

component table: storing information of the components obtained by 1.1 and 2.1, 3.1

Generalized table of Component:

task table: storing information of task inside the component obtained by 1.1 and 2.1, 3.1

Part Table storing information of the partitions obtained by 1.1, 2.1 and 3.1

Rtos table storing information obtained as a component of the system of 1.1 and 2.1, 3.1

bus table storing information of buses obtained by 1.1, 2.1 and 3.1

Device table: storing 1.1 information obtained as a component of hardware

Linkpoint table storing information of connection points obtained by 1.2 and 2.1, 3.1

Prohide table for storing information of connection points obtained by 1.2, 2.1 and 3.1 as output ports

Require table for storing information of connection points obtained by 1.2 and 2.1, 3.1 as an ingress port and Communicationchannel table for storing information of communication channels obtained by 1.3 and 2.2, 3.2

Connection table storing information of connections inside the components obtained by 1.3 and 2.2, 3.2

Dataobject table storing information of data objects obtained by 2.1, 3.1

Exception Table storing information of anomalies obtained by 1.7 and 2.1

State table storing information of states obtained by 1.4 and 3.1

Event table storing 1.9 information of the obtained Event

Transition table storing 1.8 information of state Transition obtained

Transmit table storing 1.8 obtained state and information of transition thereof

ComponentTransition Table storing 1.8 the information of the obtained component and its migration

State table of Simulink, storing 3.1 obtained state information in Simulink model

Step S4: and generating a meta-model description file in an xml format.

The function of this part is to extract all meta-model-compliant data parsed from the database and reorganize it in xml format, where the output of the simulink is handled separately, since the simulink model has no process for this element, instead of state.

The application has the advantages that the application pays attention to various entities commonly described among models, and simultaneously gives consideration to the respective characteristics of each model, so that the originally structured model can be inquired and managed in a structured mode, and a powerful support is provided for deep information development by storing and describing the models established by different modeling languages in a unified mode.

In another embodiment of the present application, taking a flight control system as an example, a specific implementation manner of a system model parsing and storing method is disclosed:

step S1: obtaining xml files of a system architecture model, a demand model and a design model (at least one model is supposed to be needed);

firstly, constructing a model file which accords with the description in the step one, uploading the model file to the system,

loading an error library file (definition file of error attachment);

1.1 setting error File Path

2. Loading an architecture for a population (architecture describing the population of a system)

For symml and simulink, only one model file needs to be loaded

Step S2: analyzing the content of elements to be analyzed in the xml file according to a certain sequence according to the xml structure which is analyzed in advance;

the program begins parsing the files of the three models:

1 find all components in the model

1.1 searching for Components in the overall architecture

The acquisition of Bus, system, device, and the three components in aadl are schematically shown in FIG. 6. When traversing the three elements respectively, judging which element type is bus, device and sys. In the parsing function, not only the component as the parent class, but also a specific generalization type, such as two generalizations of rtos and device in this case, is constructed and id is bound. It is noted at this point that in this case, both sys and device components need to traverse the linkpoint below it at the same time as traversing in order to perform the id binding operation.

1.2 searching for linkpoint belonging to the component

In the parsing process of the linkpoint, a Name (unique attribute such as id is not provided in aadl) of an upper-level component needs to be provided, and then three types of linkpoint such as busachess, dataport and eventport are searched in a component library based on the Name (unique attribute such as id is not provided in aadl)

In addition to storing as Linkpoint, for dataport and eventport, it is also bound to the generalized SyncInterface of Linkpoint, busachess is bound to AsyncMassaging, finally, according to the in and out properties of Port in aadl case and the require, provide relation between component and Linkpoint in metamodel, storing in require, provide table

1.3 Components within the lookup subsystem

The structure of the kf. Before system in the case is shown in fig. 7.

The Task, process, thread, such as some elements inside the kf. Before system in this case, are also generic to the component, and thus are put in the matchcomponent method, and the Task and processor are parsed by the Task resolution.

2 constructing communication channel based on connection

The generic messagechannel, invocationChannel classification traversal of the communication channel is performed, in the message channel, due to the characteristic of case xml, the attribute value of the source element needs to be judged first, if the source node has a context attribute, the data transmission direction is from a component to a bus, at this time, the data is processed as an buffer, and if the data transmission direction is not processed as an output buffer, the data is processed as a bus to a component.

If the destination has a context attribute, the data transfer direction is bus to component, and no context is component to bus.

After the judgment is finished, a generic MessageChannel object is created, and the binding id is obtained;

regarding an invocationChannel for transmitting a sync message, the source of the channel needs to be acquired to analyze the context value of a source node, regularizing the value, searching for a name in a specified model file according to a result, similarly acquiring the name of dest, and finally realizing the ID of a port with a specified name under a component with a specified name by itself, thereby realizing ID binding, and finally still creating a generic type and binding the ID.

Since the task in the system depends on the system, the state, event, and permission related to the error attachment need to be resolved after the system internal architecture file is loaded.

3. Parsing the exclusions

3.1 resolving the ExceptionType

3.2 resolution of name

3.3 parsing direction (communication channel for errors delivery)

If the direction attribute is out, then the linkpoint is source and vice versa is dest

4. Resolution of transition

First, the anaedelement attribute of emv Target subelement needs to be searched, the attribute value points to the ID of the event triggering the transition, and the value also needs regularization treatment;

then analyzing the start and end states, wherein the part can successfully acquire the id of the state after the state analysis is completed;

5. resolving event

6. Analysis state

State needs to be associated with component, in addition, in the case, the name information of State is stored in an error library, and the internal structure file of the system provides only a path;

for Sysml, component and link points are parsed by the block diagram, the parsing mode is basically the same as aadl and is not described in detail herein, and it should be noted that although Sysml provides xsi: id for an element, because the length format cannot be stored in the database as id, it still needs to add id itself;

for Simulink, the flow of parsing is basically consistent with aadl.

S3, inputting the parsed elements into a library and constructing relations among the elements; preferably, based on the association relationship between the elements obtained in the analysis process, constructing the relationship between the elements; wherein the association relationship is at least a parent-child relationship, a reference relationship or an inheritance relationship.

FIG. 8 is a schematic diagram showing the extraction results disclosed in the embodiment of the present application; FIG. 9 shows a schematic diagram of the results of the Rtos table disclosed in the examples of the present application; FIG. 10 is a schematic diagram of Device results disclosed in an embodiment of the present application; FIG. 11 is a diagram showing the stored results of a LinkPoint table disclosed in an embodiment of the present application; FIG. 12 is a diagram showing a schematic diagram of a provider table storage result according to an embodiment of the present application; FIG. 13 is a diagram of the results of a Require table disclosed in an embodiment of the application; fig. 14 shows a schematic diagram of a communication channel extraction result disclosed in the embodiment of the present application.

And step four, generating a meta model description file in an xml format.

In the model driven development process, since different modeling languages such as SysML, AADL and the like may be used by each unit, and the information in the models is not necessarily all relevant to development, we cannot select a single model as the final basis of development, so that all parts relevant to development purposes need to be extracted from three models to be used as descriptions, and the union of the parts is taken to describe the meta-model.

Outputting an integrated meta-model description file, wherein the corresponding relation between each model element and the meta-model in the output description file is shown in the following table 1:

table 1 correspondence between each model element and meta-model

/>

/>

/>

Those skilled in the art will appreciate that all or part of the flow of the methods of the embodiments described above may be accomplished by way of a computer program to instruct associated hardware, where the program may be stored on a computer readable storage medium. Wherein the computer readable storage medium is a magnetic disk, an optical disk, a read-only memory or a random access memory, etc.

The present application is not limited to the above-mentioned embodiments, and any changes or substitutions that can be easily understood by those skilled in the art within the technical scope of the present application are intended to be included in the scope of the present application.

Claims (10)

1. A system model parsing and storing method, the method comprising the steps of:

obtaining an xml file of the system model;

analyzing the content of the element to be analyzed in the xml file of the system model;

storing the parsed element content into a database, and constructing the relation among the elements;

the element to be analyzed is an element which is determined according to the meaning of the element name in the meta-model and corresponds to the meaning.

2. The system model parsing and storing method according to claim 1, wherein the parsing the content of the element to be parsed in the xml file of the system model includes:

determining an element path of the element to be analyzed, acquiring the element to be analyzed based on the element path to be analyzed, and analyzing the element to be analyzed to obtain the content of the element to be analyzed.

3. The system model parsing and storing method according to claim 2, wherein the modeling language of the system model is at least one of aadl, sysml, simulink.

4. The system model parsing and storing method according to claim 3, wherein,

when the modeling language of the system model is aadl, the xml file of the system model at least comprises an overall architecture; at this time, the parsing the content of the element to be parsed in the xml file of the system model includes:

sequentially analyzing components, link points, communication channels and states of the xml file of the system model; the assembly includes at least system, device, bus.

5. The system model parsing and storing method according to claim 4, wherein when the xml file of the system model further includes an error library, the parsing the content of the element to be parsed in the xml file of the system model further includes:

after the state analysis, the xml file of the system model is sequentially subjected to Process analysis, thread analysis, acceptance analysis, transition analysis and Event analysis.

6. The system model parsing and storing method according to claim 3, wherein when the modeling language of the system model is syml, the parsing the content of the element to be parsed in the xml file of the system model includes:

simultaneously analyzing the components and exception, linkpoint, task, thread, dataobject; the assembly includes at least system, device, bus;

communication channel analysis was also performed.

7. The system model parsing and storing method according to claim 3, wherein when the modeling language of the system model is simulink, the parsing the content of the element to be parsed in the xml file of the system model includes:

when analyzing the component, analyzing linkpoint, state, transition in the component; the assembly includes at least system, device, bus;

when the link point is analyzed, the corresponding dataobject is also analyzed;

when the state is analyzed, the internal transition is also analyzed;

in the analysis of the transition, the relationship between the component and the transition is also analyzed;

communication channel analysis was also performed.

8. The system model parsing and storing method according to claim 1, wherein the relationships between the elements are constructed based on the association relationships between the elements acquired in the parsing process;

wherein the association relationship is at least a parent-child relationship, a reference relationship or an inheritance relationship.

9. The system model parsing and storing method according to claim 1, wherein the method further comprises:

and extracting the elements in the database, reorganizing the elements according to an xml format, and generating a meta-model description file in the xml format.

10. The system model parsing and storing method according to claim 1, wherein the meta model comprises at least one or more of the following:

Component、Linkpoint、Connection、Class、Interface、Property、State、Transition、Condition、Action、Flow、Event、Input、Output、Message、Constraint、Fault、Failure。