A unified structural model and a method for preserving robustness of UML sequence diagrams

Abstract

The application discloses a formal model of UML sequence diagram, a unified structure and a modeling tool thereof, and a method for keeping the robustness of the UML sequence diagram under the unified structure, realizes modeling and analyzing the sequence diagram from the structure aspect, can conveniently, quickly and effectively analyze, and can guarantee the robustness of the sequence diagram in software development, thereby effectively helping object-oriented developers to overcome the gap between the analysis model and the design model. In the unified structure modeling tool provided by the application, once a sequence diagram is constructed, it can be automatically converted into the unified structure and robustness analysis is performed.

Description

Technical Field

[0001] This invention belongs to the field of software design and relates to a UML sequence diagram formal model and its robustness preservation method. Background Technology

[0002] A fatal weakness in object-oriented software development methodologies is the disconnect between software analysis and design, making a smooth transition from the analysis model to the design model impossible. The most well-known object-oriented development approach is the RUP (Real Application Process). To derive the analysis model from the use case model, then to the design model, and finally to the code, it's necessary to link use cases to objects and perform robustness analysis. Robustness analysis techniques help developers precisely bridge the gap between analysis and design. In short, robustness analysis is a method of analyzing use case text and initially identifying a set of objects for each use case. These objects are categorized into boundary objects, entity objects, and controller objects. Considering the need for operators or other entities to communicate with the outside world, "actor" objects are added. Robustness analysis is the technique for determining the relationships between these four types of objects.

[0003] In the development of object-oriented software development methodologies, the initial robustness analysis technique originated from the 1992 work of object-oriented master Jacobson, intended for analyzing the correctness of use case models. Later, with the advent of the Unified Modeling Language (UML), Jacobson adopted UML collaboration diagrams (referred to as "communication diagrams" in UML 2.x) as the analysis model. By analyzing the robustness of UML collaboration diagrams, he determined the robustness of the analysis model, thus achieving a smooth transition from the analysis model (UML collaboration diagram) to the design model (UML sequence diagram). However, how to ensure the robustness of UML sequence diagrams as object-oriented design models (and sometimes as analysis models) when refining from abstract UML sequence diagrams to concrete UML sequence diagrams, and how to ensure the correct combination and analysis of robust UML sequence diagrams, has received little research.

[0004] In the Unified Modeling Language (UML), the UML sequence diagram is one of the important interaction diagrams in UML. Sequence diagrams focus on message exchange between multiple lifelines and describe interaction relationships and occurrence rules through the sequence of exchanged messages; it is a mature visual model. The interaction relationships expressed in a sequence diagram can be represented as a two-dimensional diagram, with each independent object represented horizontally and time information represented vertically. The message passing interaction process is reflected through objects, lifelines, messages, and control focuses. The design of complex software systems often generates a large number of sequence diagram design models. Due to the enormous workload, it is impossible to completely guarantee the correctness of the model design. To improve the quality and reliability of software design, formal verification of sequence diagram models can be performed. However, because sequence diagram models lack a formal formal definition, direct formal verification is not possible. Recent research on the formal semantics of UML sequence diagrams, both domestically and internationally, has divided the semantics of sequence diagrams into two categories: Operational Semantics and Denotational Semantics. However, both semantics analyze the behavior of the sequence diagram from a behavioral perspective. Due to the involvement of concurrent behavior in the system, state explosion often occurs, making it impossible to effectively check the correctness of the sequence diagram. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes a formal model called "Unified Structure" and a method for maintaining the robustness of UML sequence diagrams under the Unified Structure.

[0006] The technical solution of the present invention is as follows:

[0007] A unified structural model, wherein the unified structure (US) is a tuple in:

[0008] ME, a finite set of model elements.

[0009] The inclusion relation is a non-reflexive partial order.

[0010] Dependency

[0011] Limitations on dependencies

[0012] The type set of model elements satisfies the following conditions:

[0013] Furthermore, the containment relation is a non-reflexive partial order relation used to model parent-child relationships. There can be multiple types of dependencies, and the number of types varies depending on the model. Each dependency (including the containment relation) can have constraints. The model elements can be divided into different types according to different viewpoints.

[0014] Furthermore, there are no cycles in the dependency chain of the unified structure (US).

[0015] This invention also provides a method for maintaining the robustness of UML sequence diagrams based on a unified structural model, as follows:

[0016] Modeling UML sequence diagrams using the Unified Structure (US),

[0017] When a UML sequence diagram is decomposed into substructures, the substructures are robust as long as the UML sequence diagram described by the Unified Structure (US) is robust.

[0018] When assembling UML sequence diagrams, the assembly is robust as long as the UML sequence diagrams described by the unified structure (US) are composable and robust.

[0019] If there are dependencies between the model elements of the UML sequence diagram modeled by the Unified Structure (US), then the refinement of the UML sequence diagram model adopts dependency refinement.

[0020] In the analysis and design of a system, as long as each model element and dependency is composable and robust during the refinement process, the system obtained from the analysis and design is robust.

[0021] Furthermore, the robustness is formally defined as follows: Using the unified structure (US) to model a sequence graph, let... These are the collections of the executor, boundary objects, control objects, and entity objects in the sequence diagram, and are set as follows: These refer to the relationship between the objects. If... Then US is robust.

[0022] This definition provides constraints on object interactions; if all communication between objects conforms to the above rules, then its sequence graph is robust.

[0023] Furthermore, the definition of composability is: Let and Two unified structures;

[0024] If satisfied Then US′ is called a substructure of US″, denoted as

[0025] If <′∪<″ is a non-reflexive partial order, then the combination between US′ and US″ is defined as in, and Then US′ and US″ are said to be combinable.

[0026] Furthermore, if two composable unified structures may have different numbers of dependency types and different dependencies, they are equivalently converted into two unified structures with the same number of dependency types before combination; if the model element type sets of two composable unified structures are different, they are equivalently converted into two unified structures with the same type set before combination.

[0027] Furthermore, let As a unified structure, in (a n ,a n Let Eref be an element refinement function of the uniform structure and Eref be a dependency refinement function of the uniform structure. If If it is composable, then the refinement of US is defined as follows:

[0028] Furthermore, the definition of the dependency refinement function is:

[0029] make and For two unified structures, let Eref be the element refinement function of the unified structure, and let Dref be the dependency refinement function of the unified structure. Make in:

[0030]

[0031]

[0032]

[0033]

[0034] In addition, the present invention also provides a unified structure modeling tool, in which once a sequence diagram is constructed, it can be automatically converted into a unified structure (US) and robustness analysis is performed.

[0035] The beneficial effects of this invention are as follows: This invention provides a formal model for UML sequence diagrams—a unified structure—that models and analyzes sequence diagrams from a structural perspective. Since structural analysis is static, it avoids state explosion caused by concurrent behaviors, thus enabling convenient, rapid, and effective analysis. This overcomes the drawback of analyzing sequence diagrams from a behavioral perspective, which leads to state explosions caused by behavioral concurrency and makes it difficult to effectively check the correctness of the sequence diagram. Furthermore, the method for maintaining the robustness of UML sequence diagrams proposed in this invention ensures the robustness of sequence diagrams in software development, effectively helping object-oriented developers overcome the gap between analysis models and design models. This invention also provides a unified structure modeling tool that automatically converts a sequence diagram into a unified structure and performs robustness analysis once the diagram is constructed. Attached Figure Description

[0036] Figure 1 This is a simplified sequence diagram from Example 1;

[0037] Figure 2 This is the design sequence diagram in Implementation Example 1;

[0038] Figure 3 This is an analysis sequence diagram of the withdrawal case in Example 1;

[0039] Figure 4 This is the design sequence diagram of the withdrawal use case in Implementation Example 1;

[0040] Figure 5 This is a diagram of the modeling tool for Example 1. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0042] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0043] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0044] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0045] In the description of the embodiments of the present invention, it should be noted that the indicated orientation or positional relationship is based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the invention is in use, or the orientation or positional relationship commonly understood by those skilled in the art, or the orientation or positional relationship commonly used when the product of the invention is in use. These are only for the convenience of describing the present invention and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the present invention. Furthermore, the terms "first" and "second" are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0046] In the description of the embodiments of the present invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set" and "connection" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances. The accompanying drawings in the embodiments are used to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0047] Example 1:

[0048] This embodiment first establishes a unified structural model (US), which is a tuple. in:

[0049] ME, a finite set of model elements.

[0050] The inclusion relation is a non-reflexive partial order.

[0051] Dependency

[0052] Limitations on dependencies

[0053] The type set of model elements satisfies the following conditions:

[0054] like Figure 1The diagram shown is a simple sequence diagram, which can be represented using the unified structure described above.

[0055] Among them: ME={a,b,c,A,B,C,m1,m2,m3,m4,m5,m6,alt,ac1,true,false}, <={(m3,ac1),(m4,ac1),(true,ac1),(false,ac1)}, λ={(m1,(a,actor)),(m2,(b,a)),(m3,(c,b)),(m4,(c,b)),(m5,(a,c)),(m6,(actor,a))}, Here, we will explain the meaning of each symbol. ME represents the set of all elements in the model, such as... Figure 1 In this context, 'a' represents an object; '<' indicates a containment relationship, used to describe parent-child relationships, such as (m3, ac1) meaning that the combo box ac1 contains the element m3. It expresses the dependency relationship between objects and classes, such as the relation (a, A) indicating that a is an object of class A; This indicates the sequence of message occurrences, which also represents a dependency relationship. For example, (m2, m1) means that message m2 occurs after message m1. λ represents a constraint on the dependency, such as (m1, (a, actor)) meaning that message m1 is sent from actor to object a. Note that here, messages represent interactive dependencies between objects. The constraint on the dependency, which represents the name of the message, is the significance of the constraint λ of the model element. This indicates the dependency relationship of the combined fragment operation, such as (ac1, alt) indicating that ac1 is an alt-type combined fragment. and These represent collections of executor objects, boundary objects, controller objects, and entity objects, respectively. A category is a collection of classes and messages; Indicates the type of combined fragment elements in the diagram, such as alt; Represents an instance of a combined fragment element, such as ac1; This represents the set of conditional elements for a combo box, such as the condition "true" for combo box ac1.

[0056] Next analysis Figure 1 Robustness of sequence graphs during decomposition, combination, and refinement.

[0057] First, robustness is formally defined as follows: Using the aforementioned unified structure (US) to model a sequence graph, let... These are the collections of the executor, boundary objects, control objects, and entity objects in the sequence diagram, and are set as follows: These refer to the relationship between the objects. If... Then US is robust.

[0058] like Figure 1 As shown, actor is the executor object, a is the boundary class object, b is the control class object, and c is the entity class object. Actor interacts with a through messages m1 and m6, a interacts with b through message m2, and b interacts with c through messages m3, m4, and m5. All their communication conforms to the above rules, therefore... Figure 1 The sequence diagram in it is robust.

[0059] Smaller sequence diagrams can be combined to form larger sequence diagrams, so it is necessary to study the robustness of sequence diagrams under combinational operations.

[0060] Combinability is defined as: Let and For two unified structures; if satisfying Then US′ is called a substructure of US″, denoted as

[0061] If <′∪<″ is a non-reflexive partial order, then the combination between US′ and US″ is defined as in, and Then US′ and US″ are said to be combinable.

[0062] When a UML sequence diagram is decomposed into substructures, the substructures are robust as long as the UML sequence diagram described by the unified structure (US) is robust. For example, let US and US′ be two unified structures.

[0063] If US′ is a substructure of US, and US is robust, then US′ is robust.

[0064] Proof: Assume that US′ is non-robust. According to the definition of a unified structure (US), let US... ′ = Therefore, there must exist two connections between objects o1′ and o2′ that make the model non-robust. Assuming it does not satisfy the rule that the executor can only communicate with the boundary object, then we have: And US′ is a substructure of US, therefore we have This means that there is direct interaction between the execution object and the control object in US', which contradicts the assumption that US is robust. Therefore, US' is robust.

[0065] When assembling UML sequence diagrams, the assembly is robust as long as the UML sequence diagrams described by the unified structure (US) are composable and robust. For example, let US and US' be two unified structures; if US and US' are composable and robust, then... It is robust.

[0066] The proof is as follows:

[0067] According to the definition of the Unified Structure (US), let... By the definition of composability, we know that US″ contains all relations and elements of US and US′ without changing the original relations. Furthermore, since both US and US′ are robust, US″ satisfies the definition of robustness. It is robust.

[0068] If two composable unified structures may have different numbers of dependency types and different dependencies, convert them into two unified structures with the same number of dependency types before combining them.

[0069] For example, the two unified structures are respectively Clearly, US′ and US″ can be converted to US1 and US2, respectively:

[0070] in

[0071] in

[0072] Clearly, US1 = US′, and US2 = US″. Furthermore, US1 and US2 have the same number of relation types. Therefore, according to the previous definition, US1 and US2 can be combined according to the same dependency types. Additionally, if the type sets of model elements are different, they can be transformed into the same type set using the same processing method as for the dependency types mentioned above.

[0073] Furthermore, the composition of unified structures possesses closure, commutativity, and associativity. For example, let US, US′, and US″ be three unified structures, and let these three structures be combinable pairwise. Then the following properties hold:

[0074] It is a unified structure.

[0075]

[0076]

[0077] The refinement of UML sequence diagrams:

[0078] make As a unified structure, in Let Eref be an element refinement function of a uniform structure and Eref be a dependency refinement function of a uniform structure. If If it is composable, then the refinement of US is defined as follows:

[0079] The definition of the dependency refinement function is:

[0080] make and For two unified structures, let Eref be the element refinement function of the unified structure, and let Dref be the dependency refinement function of the unified structure. Make in:

[0081]

[0082]

[0083]

[0084]

[0085] The above-mentioned refinement methods can be used to describe the relationship between the analysis model and the design model. Figure 2 It is a design sequence diagram, and a unified structure can be used to... Figure 2 Represented as

[0086]

[0087] SD ref This is the refined result of the analytical model in section 2.1. Its elements are similar to the SD representation in section 2.1, with class A refined to A1, class B to B1 and B2, and class C to C1 and C2. The following explains the SD... ref The elements in

[0088]

[0089] This means that in the analysis and design of a system, as long as each model element and dependency is composable and robust during the refinement process, the system obtained from the analysis and design will definitely be robust.

[0090] In this embodiment, we use a classic case study—an Automated Teller Machine (ATM) system. This system consists of three use cases: withdrawal, transfer, and deposit. Here, we only use the withdrawal use case for analysis. The withdrawal use case includes five classes: user, teller interface, withdrawal control, account, and currency distribution. These classes interact to implement the functions of the use case, which can be described using a UML sequence diagram. The analysis phase is the initial stage of design and the original basis for the design; its stability, to a certain extent, determines the stability of the software system. Here, the UML sequence diagram for the analysis phase (called the "analysis sequence diagram") uses three different construction types: "boundary classes," "control classes," and "entity classes," collectively referred to as "analysis classes." Clearly, because the number of analysis classes is relatively small, the robustness of the corresponding analysis sequence diagram is easier to determine. The analysis sequence diagram for the withdrawal use case is as follows: Figure 3 As shown. To obtain the sequence diagram (called the "design sequence diagram") during the design phase, it is necessary to refine each type in the analysis sequence diagram according to the "tracking" relationship. The class obtained after refining the analysis class is called the "design class". The correspondence between analysis classes and design classes can be set as shown in Table 1. Based on the refinement results in Table 1, construct the design sequence diagram of the withdrawal use case, as shown. Figure 4 As shown.

[0091] Table 1. Refinement results of the analytical model

[0092]

[0093] To facilitate formal transformation and robustness analysis of the sequence diagram model, Figure 3 , Figure 4 The analysis and design sequence shown is drawn using our modeling tool. Once a sequence diagram is constructed, it is automatically converted into a formal model—a unified structure—and subjected to robustness analysis. The tool's main interface is shown below. Figure 5 As shown, it has been deployed on the website http: / / 219.151.152.164:3000 / sequence and can be used directly. This tool was used to perform robustness analysis experiments on the analysis sequence diagram and the design sequence diagram, and it was able to determine whether the robustness relationship between them was maintained. The experimental results of the above example show that the design sequence diagram maintains the robustness of the analysis sequence diagram, as shown in Table 2.

[0094] Table 2 Experimental Results

[0095]

[0096] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for keeping UML sequence diagram robust based on a unified structure model, characterized in that, The uniform structure is a multi-tuple wherein: a finite set of model elements, , the inclusion relation is a non-reflexive partial order, , dependencies, In dependence on the restriction, , a set of types of model elements, satisfying the condition: ; the containment relationship is a non-reflexive partial order relationship for modeling parent-child relationship, the dependency relationship has multiple types, the number of types varies according to different models, there are restriction conditions in each dependency and containment relationship, and the model elements are divided into different types according to different viewpoints; there is no cycle in the dependency chain of the unified structure; UML sequence diagram is modeled by using the unified structure; when the UML sequence diagram is decomposed into sub-structures, as long as the UML sequence diagram described by the unified structure is robust, the sub-structures are robust; when the UML sequence diagram is combined, as long as the UML sequence diagram described by the unified structure is combinable and robust, the combination is robust; if there is a dependency relationship between the model elements of the UML sequence diagram modeled by the unified structure, the refinement of the UML sequence diagram model adopts dependency refinement; in the analysis and design of a system, as long as each model element and dependency relationship is combinable and robust in the refinement process, the system obtained by the analysis and design is robust.

2. The method for keeping UML sequence diagram robustness based on unified structure model according to claim 1, characterized in that, The robustness is defined as follows: model a sequence diagram using the uniform structure, let respectively be the set of actors, boundary objects, control objects and entity objects of the sequence diagram, and let respectively be the relations of object interactions; if , then the unified structure is robust.

3. The method for keeping UML sequence diagram robustness based on unified structure model according to claim 2, characterized in that, The combinable definition is: let and be two unified structures; If the following conditions are met then the structure is called a substructure of and is denoted by ; If is a non-reflexive partial order, then and are combinable if and only if where and then and are combinable.

4. The method for keeping UML sequence diagram robustness based on unified structure model according to claim 3, characterized in that, if two combinable unified structures have different numbers of dependency relationship types and different dependency relationships, before combination, the two unified structures are equivalently converted into two unified structures with the same number of dependency types; if the type sets of the model elements of the two combinable unified structures are different, before combination, the two unified structures are equivalently converted into two unified structures with the same type set.

5. The method for keeping UML sequence diagram robustness based on unified structure model according to claim 4, characterized in that, Let be a uniform structure, where , Let be the element refinement function of the uniform structure and be the dependent refinement function of the uniform structure, if is composable, then the refinement of the uniform structure is defined as .

6. The method for keeping UML sequence diagram robustness based on unified structure model according to claim 5, characterized in that, the definition of the dependency refinement function is: Let and be two uniform structures, let be a uniform element refinement function of the uniform structures, and let be a uniform dependence refinement function of the uniform structures, such that , , , wherein: ； ； ； ， 。

Images