KR20070058943A - Apparatus and method for evaluating of software architecture - Google Patents

Abstract

A device and a method for evaluating of a software architecture are provided to evaluate whether the architecture of a series of software products or a single product architecture derived from the architecture satisfy a nonfunctional requirement of a product group or a specific product, and correctly/typically evaluate quality related to the nonfunctional requirement. An architecture maker(100) describes architecture design information including the software architecture and the nonfunctional requirement by using a UML(Unified Modeling Language). An architecture design model generator(110) generates an architecture design model according to the architecture design information. A tradeoff analyzer(120) analyzes tradeoff among the nonfunctional requirements satisfied by the architecture based on the architecture design model. A converter(130) converts the analyzed architecture into a different typical description according to a kind of the nonfunctional requirement. A tester(140) evaluates whether the converted architecture satisfies the nonfunctional requirement.

Description

Apparatus and Method for evaluating of software architecture

1 is a block diagram schematically showing the configuration of a software architecture evaluation apparatus according to the present invention.

2 is a flow chart illustrating a software architecture evaluation method in accordance with the present invention.

<Explanation of symbols for the main parts of the drawings>

100: architecture creation unit 110: architecture design model generation unit

120: trade off analysis unit 130: conversion unit

140: test unit

The present invention relates to a software architecture evaluation apparatus and method for evaluating whether a software architecture satisfies certain non-functional requirements.

In general, an embedded system refers to a control system having hardware and software designed to drive a dedicated computer or microprocessor to perform a specific purpose or a specific function. In embedded system development, software is developed to provide differentiated services for user requirements that hardware cannot provide. Products with embedded software are expanding across industries such as telecommunications, consumer electronics, medical, aviation, and military, and the value of embedded software is expected to increase further to provide various functions.

There are many ways to evaluate software built on embedded systems. However, only a few can be used to evaluate software product line architectures, and most are methods of evaluating a single product architecture. Software architecture evaluation methods such as Software Architecture Analysis Method (SAAM) and Architecture Tradeoff Analysis Method (ATAM) are methods for evaluating a single product architecture.

The well-known architecture tradeoff analysis method (ATAM), as its name suggests, evaluates how well an architecture satisfies specific quality attributes. It also analyzes trade-offs between quality attributes. ATAM was created with reference to architectural style and quality attribute analysis methods and the former software evaluation method SAAM.

The ATAM does not have a method that can be effectively applied for evaluating a single architecture or a method that can be applied to a software product family architecture.

Examples of software product line architecture evaluation methods are the Family Architecture Assessment Method (FAAM) and the Family Architecture Evaluation (FAE).

The FAAM is a method for evaluating the architecture of information systems, focusing on the interoperability and scalability of various quality attributes, and actively incorporating product family stakeholders into the product creation process. The method also highlights realistic know-how mechanisms and techniques to enable development teams to adapt to FAAM.

However, the above conventional method can be applied to verify whether the detailed components constituting the software system satisfy the non-functional requirements such as performance / time, but can be used to verify the architecture which is a larger unit. There is a disadvantage that can not be.

Accordingly, an object of the present invention is to provide an apparatus and method for evaluating a software product family architecture and a single product architecture derived therefrom that can satisfy a non-functional requirement of a product family and a specific product.

Another object of the present invention is to provide an apparatus and method for evaluating software architecture that can formally and accurately evaluate quality related to non-functional requirements.

According to an aspect of the present invention to achieve the above object, by using an unified modeling language (UML) architecture writing unit for describing architectural design information including software architecture and non-functional requirements, described by the architecture writing unit An architecture design model generator that generates an architecture design model according to the architectural design information, and analyzes the trade-off between nonfunctional requirements that the architecture must satisfy by using the architecture design model generated by the architecture design model generator. A trade-off analysis unit, a conversion unit for converting into a formal notation according to the type of non-functional requirements to verify the architecture of the relationship between the non-functional requirements in the trade-off analysis unit, formal in the conversion unit For architectures converted to notation There is provided a software architecture evaluation apparatus comprising a test unit for evaluating whether the non-functional requirements are satisfied.

The trade-off analysis unit uses the table to determine the priority / importance of the non-functional requirements that each software product series and the specific software product must satisfy, and according to the priority / importance for the non-functional requirements that conflict with each other. Update the nonfunctional requirements.

The conversion unit automatically selects the non-functional requirements by the user or according to the priority / importance registered in the table, and converts them into other formal notation according to the type of the selected non-functional requirements.

According to another aspect of the present invention, when architecture design information using the Unified Modeling Language (UML) is input, an architecture design model should be generated according to the architecture design information, and the architecture should be satisfied using the generated architecture design model. Analyze the trade-offs between the non-functional requirements to be performed, convert the architecture from which the relationships between the non-functional requirements are analyzed into formal notations according to the type of non-functional requirements, and test request information entered by the user. A software architecture evaluation method is provided for evaluating whether an architecture converted to the formal notation satisfies a non-functional requirement.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram schematically showing the configuration of a software architecture evaluation apparatus according to the present invention.

Referring to FIG. 1, the software architecture evaluation apparatus includes an architecture generator 100, an architecture design model generator 110, a trade-off analyzer 120, a converter 130, and a tester 140. ).

The architecture preparation unit 100 creates architecture design information based on a Unified Modeling Language (UML). The architectural design information includes the architecture and nonfunctional requirements of the software system. Here, the architecture of the software system refers to a software product line architecture or a specific software product architecture.

In addition, the architectural design information describes the functional and non-functional requirements for the components of the software system. The functional requirements refer to the requirements for the organic coupling method of the components, what results each component will produce, etc. The non-functional requirements include the processing time of the entire software system or each component, the speed of producing the results, and the like. The requirements of the

The architecture design model generation unit 110 generates an architecture design model according to the architecture design information input through the architecture creation unit 100.

That is, the architecture design model generation unit 110 designs components of an appropriate software system that satisfies the non-functional requirements described in the architecture design information. This design model includes a number of components that make up the software, and additionally specifies non-functional properties such as performance and security in items representing individual components.

The trade off analysis unit 120 analyzes a trade-off between non-functional requirements that a software product series or a specific software product must satisfy in the design model generated by the architecture design model generation unit 110.

That is, the trade-off analyzer 120 has a table in which the priority / importance of non-functional requirements is determined for each software product line or product. The table may be a table previously built by an architect, a customer, a project manager, and the like by determining the priority / importance of the non-functional requirements.

Accordingly, the trade-off analyzer 120 determines the priority or importance of each non-functional requirement that each software product line or product should satisfy by using a pre-established table for the non-functional requirement that conflicts with each other. Can be removed or withheld according to priority.

There are several ways in which the trade off analysis unit 120 analyzes the trade off between non-functional requirements.

One approach is to use the Non-Functional Requirements (NFR) framework. In this framework, conflicting goals are analyzed using the Softgoal Interdependency Graph (SIG).

Each node in the SIG represents a softgoal and represents a non-functional requirement of a product. And the link between the parent goal and its descendants indicates the degree of descendants that contribute (positively or negatively) to satisfy the parent softgoal. In this process, non-functional requirements are accounted for and managed through refinement.

The conversion unit 130 converts the architecture from which the non-functional requirements are analyzed by the trade-off analyzer 120 into a formal notation according to the type of non-functional requirements. The formal notation depends on which non-functional requirements are to be evaluated, for example Rapide, Armani, Wright and the like.

The conversion performed by the conversion unit 130 is automated using a conversion tool, which is, for example, by converting a UML diagram into Rapid ADL by an aspect-oriented formal design analysis framework (FDA), UML and There are ways to map S / W architecture expressed in OCL to ADL element.

Accordingly, the conversion unit 130 converts the extended UML diagram into different formal notation according to the type of non-functional requirement.

The test unit 140 performs a test using a simulation on the formal notation converted by the converter 130.

That is, the test unit 140 determines whether the simulated design model satisfies the non-functional requirements described in the architecture design information. The test unit 140 determines the non-functional interface performance index of the individual components included in the design model according to the connection relationship. Check that you meet the requirements.

That is, the test unit 140 checks whether the software product line architecture satisfies the non-functional requirements, and checks whether the architecture of a specific product derived from the product line architecture satisfies the non-functional requirements.

2 is a flowchart illustrating a software architecture evaluation method according to the present invention.

Referring to FIG. 2, when the architecture design information input using the UML is input (S200), the architecture evaluation apparatus generates an architecture design model using the architecture design information (S202). The architectural design information refers to the architecture of the software product line (or specific software product) and the non-functional requirements to be evaluated.

That is, the user defines the architecture of a software product line (or a specific software product) using UML, and defines non-functional requirements to be evaluated.

Then, the architecture evaluation apparatus generates a revised architecture representation, that is, an architectural design model including non-functional attributes, by using the extended UML notation in order to express non-functional requirements that cannot be expressed in the UML in detail.

For example, to evaluate the response time performance of a system, information related to response time must be represented as an attribute instead of a simple OCL constraint. Only then can it be converted to a formal notation such as Rapide in a later step.

After performing step 202, the architecture evaluation device analyzes 204 trade-offs between non-functional requirements that a software product line (or a particular software product) must satisfy.

That is, the architecture evaluation apparatus has a table in which the priority or importance of non-functional requirements that each software product line (or a specific software product) must satisfy is determined so that a conflict occurs in each software product line (or a specific software product). Nonfunctional requirements may be removed or withheld in order of priority.

To assess the non-functional requirements of these architectures, it is necessary to determine which non-functional requirements of the product line and its derived product architectures will be evaluated. Non-functional requirements are determined by the sequence 1) -8) below.

1) Suggest a goal: The evaluation leader explains the purpose of the evaluation to the participants (architect, customer, project manager, etc.) and answers the question.

2) Describe the business drivers: The project manager describes which business goals motivated development and important architectural drivers (high availability, time-to-market, high security).

3) Describe the software product line architecture: The architect explains how to discover, design and model common and variable parts of the software product line architecture. It then describes the software product line architecture based on the following aspects: (1) which parts of the software product line architecture are shared and not shared among the products in the product line; (2) the variable points within the architecture and components. Quality attributes provided (3) A level of reuse that represents the relative amount of effort spent developing a reuse asset.

4) Describe the architecture of a single product: An architect describes the architecture of a single product derived from the product line to the appropriate level of detail. The description should explain all of the following aspects: (1) technical constraints such as operating system, hardware, middleware, (2) how the commonality and variability of the product line architecture was used, (3) the architectural approach used to satisfy the quality attribute requirements, and (4) How your architecture handles business drivers

5) Brainstorm and prioritize quality attributes for software product line architectures. All attendees define, prioritize and refine the quality attributes of the system for the software product line. In particular, it focuses on the aspects described by the architect in step 3. All attendees vote to prioritize the quality attributes, and the assessment leader prioritizes the quality attributes according to the vote results. The number of quality attributes can be limited according to the time schedule and the number of evaluation items. The number of quality attributes to be evaluated is finally determined in step 6.

6) Brainstorm and detail evaluation items for the software product line architecture. First, all participants brainstorm the items to be evaluated from the highest priority quality attribute to the least. The proposed evaluation items are detailed for each quality attribute. The quality attributes to be evaluated and the items to be used to evaluate them are then determined by the discussion of all participants.

7) Brainstorm and prioritize quality attributes for the architecture of a single product: As in step 5, all participants define, prioritize and refine the quality attributes of the system for each single product architecture.

8) Brainstorm and detail evaluation items for the architecture of a single product: As in step 6, all participants brainstorm the items that will be used to evaluate the prioritized quality attributes.

9) Present the results: The evaluation leader summarizes all steps and distributes a summary of which quality attributes have been given high priority and which will be evaluated.

Priority / importance for the non-functional requirements obtained by the above process is registered in the architecture evaluation apparatus in the form of a table.

Therefore, the architecture evaluation apparatus analyzes the tradeoff between non-functional requirements using the priority / importance registered in the table.

After performing step 204, the architecture evaluation apparatus converts the architecture represented by the extended UML into formal notation (S206). The formal notation may vary depending on what non-functional requirements are to be evaluated, for example Rapide, Armani, Wright, and the like.

That is, the architecture evaluation apparatus converts the extended UML diagram into different formal notation according to the type of non-functional requirement selected by the user. In other words, when the user selects a desired non-functional requirement for the formed architecture, the architecture evaluator converts the architecture into a formal notation corresponding to the selected non-functional requirement.

In the above description, the user selects a non-functional requirement in order to convert to a formal notation, but the non-functional requirement selection may be automatically selected based on a priority / importance previously registered in a table.

After performing step 206, when the test request information is input from the user (S208), the architecture evaluation apparatus performs a test according to the test request information (S210) and outputs the result (S212).

That is, the user selects a desired product family or product in order to determine whether the architectural design model converted to the formal notation satisfies the non-functional requirements of the software product family or product, and then inputs detailed information for testing. Detailed information for the test refers to, for example, response time, resource usage, and hourly workload when testing performance.

Then, the architecture evaluator applies the input test information to the product line or product selected by the user to execute a test.

The architecture evaluation device then outputs the result of the executed test. If the user is not satisfied with the output test result, the user modifies the architectural design information input in step 200.

Then, the architecture evaluation apparatus performs the process again using the modified architecture design information.

For example, suppose performance is a non-functional requirement that needs to be evaluated. Performance can be defined by response time, resource usage, and hourly workload. And evaluation of it can be done through simulation. However, the current UML does not provide any tools to measure response time or resource utilization as well as model simulation. To solve these problems, you need to support the tools you need or define formal notations that can be easily implemented. According to this approach, we use an extended UML representation to analyze the architecture and transform it into formal notation such as Rapide and Armani to analyze response time and resource usage. The architecture evaluation device then analyzes whether the architecture converted to the formal notation satisfies the non-functional requirements of the software product line or product.

Next, the non-functional requirements will be described assuming security.

In ISO7498-2, security is divided into five categories: authentication, confidentiality, authorization, integrity, and no-repudiation. It is more efficient to consider these requirements from the early stage of development, that is, from the architectural design stage, than from the implementation stage. To do this, express security requirements using extended UML diagrams, convert them to formal notation (eg Promela), and analyze whether the architecture converted to formal notation satisfies the security of the software product line or product. .

The method of the present invention as described above may be implemented in a program and stored in a recording medium in a computer-readable form. Since this process can be easily carried out by those skilled in the art will not be described in more detail.

The present invention is not limited to the above embodiments, and many variations are possible by those skilled in the art within the spirit of the present invention.

As described above, according to the present invention, unlike most architecture evaluation methods for evaluating only a single software product architecture, an apparatus and method for evaluating a software architecture capable of evaluating both a product family architecture and a product architecture derived therefrom can be provided. .

In addition, according to the present invention, since the non-functional characteristics of the product line (or specific product) architecture expressed using the extended UML are supported to be automatically converted into formal expressions such as Rapide, Armani, and Promela, the converted result is reliable. It is possible to provide an apparatus and method for evaluating software architecture that results in accuracy and saves effort and time because simulation or model checking is performed using the converted formal language.

In addition, according to the present invention, it is possible to provide an apparatus and method for evaluating a software architecture that can verify various non-functional requirements desired by an evaluator, rather than an evaluation method specialized for a specific non-functional requirement.

Claims (14)

An architecture preparation unit for describing architecture design information including a software architecture and non-functional requirements using an unified modeling language (UML); An architecture design model generation unit generating an architecture design model according to the architecture design information described by the architecture creation unit; A trade-off analyzer for analyzing a trade-off between non-functional requirements that the architecture must satisfy by using the architecture design model generated by the architecture design model generator; A conversion unit for converting a formal notation according to the type of non-functional requirements to verify the architecture from which the relationship between the non-functional requirements is analyzed by the trade-off analyzer; and A test unit for evaluating whether the architecture satisfies the non-functional requirements for the architecture converted from the formal notation Software architecture evaluation apparatus comprising a. The method of claim 1, And said software architecture comprises a software product line or a specific software product. The method of claim 1, And the architecture design model generation unit generates an architecture design model using an integrated modeling language extended so that the software architecture described by the architecture creation unit includes the non-functional requirements. The method of claim 1, The trade-off analysis unit is a software architecture evaluation apparatus, characterized in that there is a table in which the priority / importance of non-functional requirements for each software product series and specific software products. The method according to claim 1 or 4, The trade-off analysis unit uses the table to determine the priority / importance of the non-functional requirements that each software product series and the specific software product must satisfy, and according to the priority / importance for the non-functional requirements that conflict with each other. Software architecture evaluation apparatus, characterized in that for updating the non-functional requirements. The method of claim 1, The trade off analysis unit software architecture evaluation device, characterized in that for analyzing the trade-off between non-functional requirements using the NFR framework. The method of claim 1, The formal notation is a software architecture evaluation device, characterized in that one of Rapid (Arapide), Armani (Wright). The method according to claim 1 or 4, The converting unit automatically selects a non-functional requirement by a user or according to priority / importance registered in the table, and converts it into another formal notation according to the type of the selected non-functional requirement. Architecture evaluation device. The method of claim 1, And the test unit performs a test according to test request information input by a user. The method of claim 9, And the test request information includes detailed information about a software product line or specific software product information and non-functional requirements to be tested. Generating architectural design model according to the architectural design information, when architectural design information using an unified modeling language (UML) is input; Analyzing trade-offs between non-functional requirements that the architecture must satisfy using the generated architecture design model; Converting the architecture in which the relationship between the non-functional requirements is analyzed into a formal notation according to the type of non-functional requirement; and Evaluating whether the architecture converted to the formal notation satisfies the non-functional requirements according to the test request information input by the user. Software architecture evaluation method comprising a. The method of claim 11, When architectural design information using the Unified Modeling Language (UML) is input, generating an architectural design model according to the architectural design information may include: Receiving, by the user, architectural information and non-functional requirements of a software product line or a specific software product using the Unified Modeling Language (UML); And generating an architectural design model based on the input architecture information and the non-functional requirements using an extended integrated modeling language. The method of claim 11, Evaluating whether the architecture converted to the formal notation according to the test request information input by the user satisfies the non-functional requirements, Receiving a test request information on the selected architecture when a software product line or a specific software product is selected from the architecture design model; And performing a test according to the input test request information and outputting a result of the test. The method of claim 13, And the architecture design information is modified by the test output result.

Images