JP2007086929A - Software design support system and method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a software design support system and method that design reusable components while associating architectures of a plurality of products of a product line with functional features and nonfunctional features. <P>SOLUTION: The software design support system comprises a functional feature table 2, a nonfunctional feature table 3, an architecture table 5 for storing definitions of hypotheses of products of a target product line and architectures of existing products, an architecture-functional feature relationship table 6 for storing definitions of relationships between architectures and functional features, a functional feature-reusable component relationship table 7 for storing definitions of relationships between functional features and reusable components, an architecture setting part 8 for setting information in the architecture table 5, and a reusable component setting part 10 for setting information about reusable components associated with functional features in the functional feature-reusable component relationship table 7. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a technology for designing a reuse component by evaluating a hypothesis or existing architecture of a plurality of products when designing software of a product having a product line (product line) including embedded software.

  As a conventional example of software design support, Japanese Patent Laid-Open No. 10-40088 (Patent Document 1) uses a “functional specification type” that uses a functional hierarchy to determine the reusability of software specifications and development products based on the software specifications. Judgment and separation of reusable parts are performed.

  Similarly, Kyo C Kang et al. 5 “FORM: A feature-oriented reuse method with domain-specific reference architectures” (Non-patent Document 1) is expanded into a functional hierarchy as shown in “Mapping to FORM architecture” in FIG. The outline of the method of mapping the functional characteristics to the architecture is described. In this case, the reference architecture assumes a single architecture. In addition, the characteristic model is layered into Capabilities, Operating Environment, Domain Technologies, Implementation Technologies, and Reference Architecture is Subsystem, Process. , Module (module) models. The specific mapping of the functional characteristics to the architecture has only described the concept.

The paper “Aspect-Oriented Analysis for Software Architecture” written by Tomoji Kishi (Non-Patent Document 2) shows that the architecture analyzes the functional characteristics (services) and quality characteristics (non-functional characteristics) as shown in FIG. We categorize the bundling by quality characteristics common to them, and further evaluate whether they depend on the platform or not, and extract the architecture (reusable software block) that depends on the platform.
Japanese Patent Laid-Open No. 10-40088 Kyo C Kang et al. 5 FORM: A feature-oriented reuse method with domain-specific reference architectures, Annals of Software Engineering 5 (1998) Kishi Tomoji, “Aspect-Oriented Analysis for Software Architecture”, Software Engineering Workshop Report, Vol.131, No.8, pp.57-64 (2001)

  The invention described in Patent Document 1 uses a functional hierarchy, but there is no analysis from the viewpoint of architecture such as hardware configuration, basic software, and task structure, which are restrictions in embedded software, and the architecture changes Therefore, it is difficult to accurately and efficiently implement the reuse design with embedded software.

  The content of the paper disclosed in Non-Patent Document 1 describes the outline of a method for mapping the functional characteristics developed in the functional hierarchy to the architecture, but the object to be mapped only mentions a single architecture. It does not describe specific correspondence of functional characteristics to the architecture, division of functional characteristics, and merge from the functional characteristics of reusable components, and it is difficult to develop specific design work.

  The content of the paper disclosed in Non-Patent Document 2 is that the architecture derives a category from the non-functional characteristics such as functional characteristics and performance, and further derives the architecture based on the constraints of the basic software. There is no description of how to deal with changes, the procedure is complicated, and there are many parts that do not match the actual situation.

  Therefore, the present invention prevents reuse of errors and leaks by reducing the number of work steps by designing reusable components while associating the architecture, functional characteristics, and non-functional characteristics of multiple products in a product line (product line). By doing so, the purpose is to improve quality in software development, to meet short delivery times, and to reduce costs.

  In order to solve the above-mentioned problems, the present invention provides a software design support apparatus that supports design of product software having a product series while associating a plurality of architectures with functional characteristics, and the assumption of a product series product or an existing architecture. Architecture storage means for storing definitions, functional characteristic storage means for storing definition of hierarchical functional characteristics, non-functional characteristic storage means for storing definition of hierarchical non-functional characteristics, and architecture in the architecture storage means Architecture setting means for setting; matrix generating means for reading out the function characteristics stored in the functional characteristic storage means and the architecture set in the architecture storage means; and generating a matrix describing the correspondence between the functional characteristics and the architecture; and Generate by matrix generator Reusable component design means for deploying functional characteristics consistent with the architecture by mutually linking the functional characteristics, the non-functional characteristics and the architecture on the generated matrix and designing a reusable component based on the functional characteristics; , Including.

  According to the present invention, the functional characteristics of the characteristic model are applied to the hypothesis or the architecture of an existing product, the functional characteristics consistent with the architecture are expanded, the functional characteristics are divided as necessary, and the functional characteristics are reproduced based on the expanded functional characteristics. It is possible to easily design the usage component. In addition, it is possible to cope with changes in the architecture subsystem configuration and task configuration by evaluating multiple architectures in the product series, for example, by continuously defining and evaluating the architecture subsystem configuration and task configuration. Furthermore, if a new architecture is generated, it can be easily handled by using the same method.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a block diagram showing an outline of the configuration of a software design support apparatus according to an embodiment of the present invention. In FIG. 1, a software design support apparatus according to an embodiment of the present invention includes a server 1 that stores a program and executes processing operations of the following processing units and data setting / acquisition for the following tables, and hierarchical functional characteristic definitions. Functional characteristic table 2 for storing the function, non-functional characteristic table 3 for storing the definition of the hierarchized non-functional characteristic, and the function / non-functional characteristic relation for storing the definition of the relation between the hierarchical functional characteristic and the non-functional characteristic A table 4, an architecture table 5 that stores hypotheses about products of the target product line, and architecture definitions of existing products, an architecture function characteristic relation table 6 that stores definitions of relationships between architectures and functional characteristics, and functional characteristics Functional property reuse component relation table 7 for storing the definition of reuse component relation, An architecture setting processing unit 8 for setting information in the cutout table 5, a functional characteristic mapping processing unit 9 for mapping functional characteristics to the architecture and setting information in the architecture functional characteristic related table 6, and a reusable component associated with the functional characteristics The reusable component setting processing unit 10 for setting information in the functional property reuse component relation table 7, and mapping information for displaying the functional property / non-functional property mapping, the architecture / functional property mapping, and the functional property / reuse component mapping information The display processing unit 11 is connected to the server 1 via a network, and includes a client 12 for setting data, starting processing, and displaying data.

  FIG. 2 is a diagram showing a specific example of a hypothesis / existing architecture according to the embodiment of the present invention. In FIG. 2, the architecture describes the relationships among subsystems, tasks, basic software, and subsystems for products in the product line. The example of FIG. 2 shows that there is some relationship between subsystem a and subsystem n, and the subsystem is task 1, 2, 3,..., N, infrastructure software 1, 2,. Includes C (common). The reason why the hypothesis / existing architecture is used is that it includes a hypothesis prepared in advance or an existing one.

  FIG. 3 is a diagram showing an example of items set in the functional characteristic table 2 shown in FIG. As shown in FIG. 3, in the functional property table, the domain name 21 and the property name 22 are indexes. The domain name 21 is input as a result of the domain analysis, and the characteristic name 22 stores the highest characteristic of the characteristic analysis. The "characteristics" defined in this characteristic table are the general ones introduced in Krzysztof Czarnecki et al. 1 "Generative Programming Methods, Tools, and Applications" Addison-Wesley, pp39-48 (2000) (Reference 1). The definition, that is, the property defined as the property of the system directly affecting the end user, defined by FODA (Feature-Oriented Domain Analysis method) is used. Specifically, it refers to the aspect, quality, or characteristics of the software system or system that is visible and visible to the end user, such as transmission characteristics that the user must determine when purchasing a car (eg, automatic or manual) Is equivalent to describing. Then, the lower level characteristic names that are sequentially hierarchized below the characteristic name 22 are expanded, and the characteristic name obtained by dividing the uppermost characteristic into characteristics is entered in the lower one level characteristic name 23. In addition, the item shown in (2) Attribute Item shown in the lower part of FIG. Similarly to the lower first level characteristic name 23 and the attribute item 24, the upper function characteristic is obtained by dividing the upper functional characteristic into the lower two level characteristic name 25, the attribute item 26, the lower n level characteristic name 27, and the attribute item 28. The specified characteristic name and the attribute item of the functional characteristic are stored.

  “(2) Attribute item” shown at the bottom of FIG. 3 is configured as follows. The classification 31 stores data indicating whether the characteristic is a common characteristic, an optional characteristic, or an OR characteristic. This information is essential information for constructing the characteristic model. The lower map 32 describes the relationship with each lower function of the level. Further, the relation table ID 33 stores the ID of the function / non-function characteristic relation table 4 shown in FIG. 1 showing the relation between the function characteristic and the non-function characteristic. Thereby, the non-functional characteristic corresponding to the functional characteristic is identified. In the remarks 34, arbitrary information is entered. Note that “(2) attribute item” shown at the bottom of FIG. 3 can be arbitrarily added.

  FIG. 4 is a diagram showing an example of items set in the non-functional characteristic table 3 shown in FIG. As shown in FIG. 4, the domain name 41 is an index in the non-functional characteristic table. As described above, the domain name is input based on the result of the domain analysis. The quality attribute 42 describes quality classification. As the classification to be described, for example, quality characteristics of ISO / IEC 9126 are set by default. As the quality characteristic 44, for example, a quality characteristic converted into a quality characteristic by using a quality table of QFD (Quality Function Deployment) (JIS Q 9025) is used. The scenario n level name 46 describes, for example, a scenario in which the quality characteristic 44 is developed from the viewpoint of input / status / response. The “scenario” defined in this characteristic table is described in “Evaluating Software Architectures” by Clements et al. 2 Addison-Wesley, pp52-55 (2002) (reference document 2) “Short description of interaction between stakeholders and system” The one defined as “is” is used.

  “(2) Attribute item” shown in the lower part of FIG. 4 is configured as follows. In the “(1) non-functional characteristic table” shown at the top of FIG. 4, attribute items 43, 45, and 47 are provided as attribute items corresponding to the quality attribute 42, the quality characteristic 44, and the scenario n level name 46. However, only the attribute item 47 provided corresponding to the scenario n level name 46 is taken up as an example here. The classification 51 in “(2) Attribute item” stores data indicating whether the scenario is related to input, status, or response. This information is additional information and is not essential. In the lower map 52, if there is a relationship with each lower function of the level, it is described. In the relation table ID 53, the ID of the function / non-function characteristic relation table 4 shown in FIG. 1 indicating the relation between the function characteristic and the non-function characteristic is stored. A function characteristic corresponding to the non-functional characteristic is identified by the association table ID 53. The importance level 54 stores a value obtained by evaluating the importance level of the non-functional characteristic in five stages. The risk 55 stores a value obtained by evaluating the risk of the non-functional characteristic in five stages. Risks include, for example, unclear judgment requirements and insufficient consideration of judgment. In remarks 56, any necessary information is entered. It should be noted that the classification 51 in the attribute items 43 and 45 not illustrated is blank at this stage and is omitted because there is nothing to fill. And "(2) attribute item" shown in the lower part of FIG. 4 can be arbitrarily added and can be filled in as appropriate.

  FIG. 5 is a diagram showing an example of items set in the function / non-functional characteristic relation table 4 shown in FIG. The function / non-function characteristic relation table shown in FIG. 5 is configured as follows. That is, the ID 61 describes a unique number for a record arbitrarily assigned to identify the record in the function / non-function characteristic relation table 4. The function characteristic table item name 62 stores the characteristic name 22 of the functional characteristic table 2 related to the record. In the case of a lower-level characteristic, the upper characteristic name up to the highest level is also described. In the non-functional characteristic table item name 63, a non-functional characteristic name related to the characteristic name 22 of the functional characteristic table 2 related to the record (see the quality attribute 42, the quality characteristic 44, and the scenario n level name 46 in FIG. 4). Store. In the case of a lower-level characteristic, the upper characteristic name up to the highest level is also described. In the condition description 64, if there is a condition regarding the relation between the functional characteristic and the non-functional characteristic, the condition is stored.

  FIG. 6 shows an example of items set in the architecture table 5 shown in FIG. The architecture describes the relationship between subsystems, tasks, basic software, and subsystems for products in the product line. FIG. 2 shows a specific example of the hypothesis / existing architecture. The architecture table shown in FIG. 6 is configured as follows. That is, the ID 71 describes a unique number for a record arbitrarily assigned to identify the record of the architecture table 5. The architecture name 72 stores the name given to the hypothesis / existing architecture of the product in the product line (product line). The architecture attribute 73 stores common attributes of subsystems in the architecture and attribute information related to the relationship between the subsystems. The subsystem name 74 stores a name assigned to the subsystem in the architecture. The subsystem attribute 75 stores attribute information relating to common attributes within the subsystem, tasks between subsystems, and relationships between infrastructure software. The task name 76 stores the task name in the subsystem. The task attribute 77 stores an attribute relating to a task such as a task start cycle or a start event.

  FIG. 7 is a diagram showing a specific example of the architecture table item shown in FIG. 6. As an example, “A1, A2” is set in the architecture name 72, and the architecture name “A1” is set in the subsystem name 74. Correspondingly, the subsystem name “keypad” and the subsystem “main body” as the subsystem name 74, and the subsystem name “a1, a2, a3” corresponding to the subsystem “tenkey” as the task name 76 are the subsystem “main body”. “B1” is set in correspondence with each other, the subsystem name 74 is set as the subsystem “tenkey”, and the task name 76 is set as “a21” corresponding to the architecture name “A2”. In the above, a different number is set uniquely for ID 71 corresponding to the task name, and a different task cycle is set for task attribute 77 corresponding to the task name.

  FIG. 8 is a diagram showing an example of items set in the architecture function characteristic relation table 6 shown in FIG. The architecture function characteristic relation table shown in FIG. 8 is configured as follows. That is, in ID 81, a unique number is described in an arbitrarily assigned record for identifying the record of the architecture function characteristic relation table 6. The architecture table item name 82 stores the task name 76 of the architecture table 5 related to the record and the subsystem name 74 above the task (see FIG. 6). The functional characteristic table item name 83 stores a functional characteristic name related to the architecture table item name 82 related to the record. In the case of a lower-level characteristic, the upper characteristic name up to the highest level is also described. In the condition description 84, if there is a condition regarding the relationship between the architecture and the functional characteristics, the condition is stored.

  FIG. 9 is a diagram showing a specific example of the architecture function characteristic related table item shown in FIG. 8. For example, the architecture table item name 82 with ID 81 “1” is “A1-a1”, and the function characteristic table item name is shown. 83 is set to “log”, and the condition description 84 is set to “base-independent”, the architecture table item name 82 with ID 81 “5” is “A1-a2”, and the function characteristic table item name 83 is set. Is “inter-subsystem communication-low-subsystem low-speed communication”, and the condition description 84 is set to be “base-dependent”.

  FIG. 10 is a diagram showing an example of items set in the functional property reuse component relation table 7 shown in FIG. The functional property reuse component association table shown in FIG. 10 is configured as follows. That is, the ID 91 describes a unique number for a record arbitrarily assigned to identify a record in the functional property reuse component relation table 7. The function characteristic table item name 92 stores the function characteristic name. In the case of a lower-level characteristic, the upper characteristic name up to the highest level is also described. The reuse component name 93 stores the reuse component name corresponding to the functional characteristics of the record. The function characteristic appearance frequency 94 stores the number of architecture IDs in which the functional characteristic has appeared.

  FIG. 11 is a diagram showing a specific example of the functional property reuse component related table item shown in FIG. 10. For example, the functional property table item name 92 with ID 91 “1” is “log”, and the reuse component name 93 is set to “C1” and the function characteristic appearance frequency 94 is set to “5”, and the function characteristic table item name 92 with ID 91 “2” is “overall management-overall management 1” and reused. The component name 93 is set to “C2” and the function characteristic appearance frequency 94 is set to “2”. Similarly, the function characteristic table item name 92 having the ID 91 of “3” is “overall management-overall management 2”. The used component name 93 is set to “C21”, and the function characteristic appearance frequency 94 is set to “3”.

  FIG. 12 is a flowchart for explaining the processing operation in the architecture setting processing unit 8 shown in FIG. In this processing operation, the architecture setting processing operation is started by the input of the screen shown in FIG. The architecture setting processing screen of FIG. 14 is set so that the architecture name is “A1” and the base software is “Itron, transmission processing”, and “numerical key”, “main body”, “system control” are used as subsystems. , And subsystem attributes, tasks, and task attributes are associated and set for each subsystem. Returning to FIG. 12, in step (step is expressed as S in the figure) 11, the set architecture information is read and the contents are stored in the architecture table 5.

  13A and 13B are flowcharts for explaining the processing operation in the functional characteristic mapping processing unit 9 shown in FIG. This processing operation is started by a display request for a screen for performing the function characteristic mapping processing shown in FIGS. 15, 16, and 17 as a specific example. 15 is a first specific example of a display screen for mapping the characteristic function to the architecture A1, FIG. 16 is a specific example of a display screen for mapping the characteristic function to the architecture Ak, and FIG. The 2nd example of the display screen for mapping to architecture A1 is shown. In this processing operation, an architecture name is designated as a parameter.

  13A and 13B, in step 21 (in the figure, step is represented as S. The same applies hereinafter) 21, architecture table 5 and functional characteristic table 2 are read. If the architecture function characteristic related table 6 has already been set, the table is also read. In step 22, the screen for performing the function characteristic mapping process shown in FIGS. 15, 16, and 17 is displayed as a specific example. In this case, the architecture and the function characteristic item are initially displayed, and if the relationship between the architecture and the function characteristic item is already set in the architecture function characteristic relation table 6, the relation (indicated by a white circle “◯”) is also displayed.

  In step 23, the set mapping information is read. In the setting, the designer refers to the data of the functional characteristics and the non-functional characteristics with reference to the data of the functional characteristics and the non-functional characteristics, determines the attributes of the subsystem and the task that can realize the characteristics, and assigns the functional characteristics to the task. In step 24, function characteristics in which the same function characteristics are mapped to a plurality of tasks are extracted, and guidance is provided to the designer who is operating the screen. This is performed in order to prompt the judgment as to whether or not to divide the functional characteristics by changing the transmission processing (for example, protocol) corresponding to the architecture. Note that it is not necessary to divide a plurality of tasks, such as a log function, which may have the same function.

  In step 25, it is checked whether there is a change in the base software of the architecture set by the parameter of the architecture table 5 and the previous architecture attribute. This is performed in order to separate the reusable function and the function depending on the base software such as the OS and to effectively reuse the base software such as the OS when there is a change depending on the architecture. In step 26, it is determined that the base software has changed and the previous architecture is not the same. If there is the same base software in the previous architecture, it is determined that the function attribute has already been evaluated. In this case, the process proceeds to step 28. If YES in step 26, the process proceeds to step 27, and in step 27, the basic software change guidance is given to the designer who is operating the screen.

  In FIG. 13B, in step 28, the functional characteristic information input and set by the designer is read. In this case, it should be noted that the function characteristics may be divided and input in the guidance in step 27. In step 29, it is determined whether or not there is a division of functional characteristics by comparing the current information with the read information. If there is a division of the functional characteristics in step 29, the process proceeds to step 30. In step 30, in order to update the function / non-functional characteristic related table 4 in accordance with the division of the functional characteristics, the non-functional characteristic table 3 and The update guidance of the function / non-function characteristic relation table 4 is displayed.

  In step 31, information in the non-functional property table 3 and the function / non-functional property related table 4 changed by the designer is read. In step 32, the information of the functional characteristic table 2, the non-functional characteristic table 3, and the functional / non-functional characteristic related table 4 is written in the respective tables, and the information is updated. The updated information becomes product series (product line) characteristic information. If the processing ends in step 32 and the functional characteristics are not divided in step 29, the record of the architecture functional characteristic related table 6 is updated in step 33 in accordance with the addition or change of the functional characteristics. Note that, in the course of the processing in FIG. 13A and FIG. 13B, related tables are shown on the right side of FIG. 13A and FIG.

  FIG. 18 is a flowchart for explaining the processing operation in the reuse component setting processing unit 10 shown in FIG. This processing operation is activated by a screen display request for the reusable component setting processing shown in FIGS. 19, 20, and 21 as a specific example. 19 is a first specific example of a display screen for reusable component setting processing, FIG. 20 is a specific example of a display screen for reusable component setting processing after architecture Ak evaluation, and FIG. 21 is a reusable component setting. The 2nd specific example of the display screen for processing is shown. In this processing operation, an architecture name is designated as a parameter.

  In FIG. 18, in step 41 (step is expressed as S. The same applies hereinafter) 41, the architecture table 5, the function characteristic table 2, and the architecture function characteristic related table 6 are read. If the reuse component has already been set in the function characteristic reuse component relation table 7, the function characteristic reuse component relation table 7 is also read. In step 42, the screen for the reusable component setting process shown in FIGS. 19, 20, and 21 is displayed as a specific example. The screen shown in FIG. 19 displays an architecture subsystem, tasks, functional characteristics, and a map of architecture and functional characteristics (indicated by white circles “◯”). If a reuse component has already been set in the functional property reuse component relation table 7, this information is also displayed.

  In step 43, the function characteristic appearance frequency counted in architecture ID units is incremented with reference to the function characteristic reuse component relation table 7. In step 44, it is evaluated whether or not there is a functional characteristic having an appearance frequency of 1. When the evaluation in step 44 is YES, the process proceeds to step 45, and in step 45, guidance that is not to be reused is given to the designer who is operating the screen. Then, it is requested to determine whether or not to consider the functional characteristic for a specific product by the guidance. When the evaluation in step 44 is NO, the process proceeds to step 46, and the reused component name input and set by the designer in step 46 is read. In step 47, the set reuse component name is stored in the functional property reuse component relation table 7. Note that, in the course of processing in FIG. 18, related tables are shown on the right side of FIG. 18 for reference by arrow lines.

  As described above, according to the present embodiment, a preliminarily prepared hypothesis or an off-the-shelf architecture is set, the functional characteristics of the characteristic model are applied to the above-set hypothesis or off-the-shelf architecture, and functional characteristics consistent with the architecture are developed. It is possible to divide the functional characteristics as necessary and easily design the reuse component based on the developed functional characteristics. In addition, it is possible to cope with changes in the subsystem configuration and task configuration by evaluating a plurality of architectures in the product series, for example, by continuously defining and evaluating the subsystem configuration and task configuration of the architecture. Furthermore, when a new architecture occurs, it can be easily handled in exactly the same way as the hypothesis and the existing architecture evaluation.

  In addition, since the reusable components are merged from the functional characteristics, the reusable component extraction operation can be easily and accurately performed. As described above, design and application of reusable components while associating the architecture, functional characteristics, and non-functional characteristics of multiple products, thereby preventing errors and leaks from being mixed and reducing work man-hours. As a result, productivity improvement, quality improvement, quick delivery, and cost reduction in software development can be achieved. In any case, the software design support apparatus according to the present embodiment is very advantageous because it is in conformity with the actual design of software having hardware and infrastructure software constraints such as firmware design.

  FIG. 22 is a diagram showing a first specific example of mapping information display processed by the mapping information display processing unit 11 shown in FIG. The mapping information display shown in FIG. 22 displays function / non-functional characteristic related information on the basis of information on functional characteristics and non-functional characteristics. The mapping information display processing unit 11 displays the specified functional characteristics / non-functional characteristics. Functional characteristic data is acquired from the functional characteristic table 2 and the non-functional characteristic table 3, and a functional characteristic tree is displayed by the data of the table (see the upper left portion of the display screen shown in FIG. 22). The illustrated functional property tree shows an example of the product line / tenkey subsystem. Similarly, the non-functional characteristic tree is displayed by the data of the table (see the lower left part of the display screen shown in FIG. 22). Further, the lower-level matrix items (frame items) designated with reference to the function / non-functional characteristic relation table 4 are displayed (see the right side of the display screen shown in FIG. 22). Data related to matrix items (frame items) is displayed as a map (white circle ‘O’).

  FIG. 23 is a diagram illustrating a second specific example of the mapping information display displayed by the mapping information display processing unit 11 illustrated in FIG. The mapping information display shown in FIG. 23 is for mapping and displaying the architecture function characteristic related information based on the information about the architecture and the function characteristics, and the mapping information display processing unit 11 displays the data of the designated architecture and function characteristics as the architecture. Subsystems obtained from the table 5 and the functional characteristic table 2 and associated with the architecture are displayed by the data of the table (see the upper left of the display screen shown in FIG. 23). Note that the subsystems associated with the illustrated architecture are for architecture A1. Further, the function characteristic tree is displayed by the data of the table (see the lower left portion of the display screen shown in FIG. 23). The illustrated functional property tree shows product line functional properties. Further, the matrix function items (frame items) about the function characteristics and architecture designated with reference to the architecture function characteristics relation table 6 are displayed (see the right side of the display screen shown in FIG. 23). Data related to matrix items (frame items) is displayed as a map (white circle ‘O’).

  FIG. 24 is a diagram illustrating a third specific example of the mapping information display displayed by the mapping information display processing unit 11 illustrated in FIG. The mapping information display shown in FIG. 24 displays the function characteristic reuse component related information on the basis of the information on the function characteristics and the architecture, and the mapping information display processing unit 11 displays the specified function characteristic data as the function characteristics. The function characteristic tree obtained from the table 2 is displayed with the data of the table (see the left side of the display screen shown in FIG. 24). The illustrated functional property tree shows product line functional properties. FIG. 25 shows a specific example of the function characteristic tree. Regarding the display method of the functional characteristic tree, the notation method is specifically described in Reference Document 1 introduced above, so please refer to it appropriately.

  In addition, the architecture data is acquired from the architecture table 5, the function characteristics and the related information of the architecture are acquired from the architecture function characteristics related table 6, and the function characteristics specified by referring to the function characteristics reuse component related table 7 Mapping information is displayed for matrix items (frame items) for the used components (see the right side of the display screen shown in FIG. 25).

  As described above, the mapping information display shown in FIGS. 22 to 24 is shown as a table including at least a characteristic tree (hierarchical diagram) and a matrix, and thus related items are clearly shown. It is possible to prevent mistakes and leaks from being mixed, and to reduce work man-hours.

It is a block diagram which shows the structure outline | summary of the software design support apparatus which concerns on embodiment of this invention. It is a figure which shows the specific example of the hypothesis / existing architecture which concerns on embodiment of this invention. It is a figure which shows the example of an item set to the functional characteristic table shown in FIG. It is a figure which shows the example of an item set to the non-functional characteristic table shown in FIG. It is a figure which shows the example of an item set to the functional / non-functional characteristic related table shown in FIG. It is a figure which shows the example of an item set to the architecture table shown in FIG. It is a figure which shows the specific example of the architecture table item shown in FIG. It is a figure which shows the example of an item set to the architecture function characteristic related table shown in FIG. It is a figure which shows the specific example of the architecture function characteristic related table item shown in FIG. It is a figure which shows the example of an item set to the functional characteristic reuse component related table shown in FIG. It is a figure which shows the specific example of the functional characteristic reuse component related table item shown in FIG. 3 is a flowchart for explaining a processing operation in an architecture setting processing unit shown in FIG. 1. 3 is a flowchart for explaining a processing operation in a functional characteristic mapping processing unit shown in FIG. 1. 3 is a flowchart for explaining a processing operation in a functional characteristic mapping processing unit shown in FIG. 1. It is a figure which shows the specific example of the architecture setting process screen which concerns on embodiment of this invention. It is a figure which shows the 1st specific example of the display screen for mapping the characteristic function which concerns on embodiment of this invention to architecture A1. It is a figure which shows the specific example of the display screen for mapping the characteristic function which concerns on embodiment of this invention to architecture Ak. It is a figure which shows the 2nd specific example of the display screen for mapping the characteristic function which concerns on embodiment of this invention to architecture A1. It is a flowchart for demonstrating the processing operation in the reuse component setting process part shown in FIG. It is a figure which shows the 1st specific example of the display screen for the reuse component setting process which concerns on embodiment of this invention. It is a figure which shows the specific example of the display screen for the reuse component setting process after architecture Ak evaluation which concerns on embodiment of this invention. It is a figure which shows the 2nd specific example of the display screen for the reuse component setting process which concerns on embodiment of this invention. It is a figure which shows the 1st specific example of the mapping information display processed by the mapping information display process part shown in FIG. It is a figure which shows the 2nd specific example of the mapping information display processed by the mapping information display process part shown in FIG. It is a figure which shows the 3rd specific example of the mapping information display processed by the mapping information display process part shown in FIG. It is a figure which shows the specific example of the functional characteristic tree which concerns on embodiment of this invention. It is a figure for demonstrating the outline | summary of the conventional system which maps a functional characteristic to an architecture. It is a figure for demonstrating the outline | summary of the conventional system which extracts the architecture depending on a foundation | substrate.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Server 2 Functional characteristic table 3 Non-functional characteristic table 4 Functional / non-functional characteristic related table 5 Architecture table 6 Architectural functional characteristic related table 7 Functional characteristic reuse component related table 8 Architecture setting processing part 9 Functional characteristic mapping processing part 10 Reuse Component setting processing unit 11 Mapping information display processing unit 12 Client

Claims (7)

  In a software design support apparatus that supports design of product software having a product series while associating multiple architectures with functional characteristics, architecture storage means for storing hypotheses about the products of the product series or definitions of existing architectures, and hierarchization Functional characteristic storage means for storing defined functional characteristic definitions, non-functional characteristic storage means for storing hierarchical non-functional characteristic definitions, architecture setting means for setting an architecture in the architecture storage means, and the functional characteristic storage Reading out the function characteristics stored in the means and the architecture set in the architecture storage means, generating a matrix describing the correspondence between the function characteristics and the architecture, and on the matrix generated by the matrix generation means Functional characteristics Reusable component design means for developing a reusable component design based on the non-functional property and the architecture by coordinating the architecture with each other to develop a functional property consistent with the architecture. Design support device.   2. The software design support apparatus according to claim 1, wherein the architecture setting means defines subsystems, basic software, and tasks and attributes as an architecture, and stores the set architecture in the architecture storage means.   The reusable component design unit expands the subsystem, the base software, the task, and the attributes of the architecture on the matrix generated by the matrix generation unit, and the correspondence relationship between the expanded architecture and the functional characteristics The reusable component is extracted from the software design support apparatus according to claim 1.   4. The software design support apparatus according to claim 3, wherein the reuse component design means measures the functional characteristic appearance frequency and extracts the reuse component based on the measured functional characteristic appearance frequency.   4. The software design support apparatus according to claim 3, wherein the reusable component design means displays mapping information in a tree hierarchy diagram and a table when extracting the reusable component.   In a software design support method that supports design of product software having product series by associating multiple architectures with functional characteristics, an architecture table that stores hypotheses about the products in the product series or definitions of existing architectures, and hierarchical functions Generates a functional characteristic table that stores characteristic definitions and a non-functional characteristic table that stores hierarchical non-functional characteristic definitions, sets the architecture in the generated architecture table, and stores the functional characteristics and settings Read out the generated architecture, generate a matrix that describes the correspondence between the functional characteristics and the architecture, and develop functional characteristics that are consistent with the architecture by linking the functional characteristics, non-functional characteristics, and the architecture on the generated matrix. The relevant Software design support method characterized by comprising, for performing a design of reusable components, on the basis of the Performance Characteristics.   An architecture table that stores hypotheses or existing architecture definitions for products in a product line, a functional characteristic table that stores hierarchical functional characteristic definitions, and a non-functional characteristic table that stores hierarchical non-functional characteristic definitions A software design support program that supports design of product software having a product line by associating multiple architectures with functional characteristics, and storing the procedure for setting the architecture in the generated architecture table on the computer. Read out the functional characteristics and the configured architecture, and generate a matrix that describes the correspondence between the functional characteristics and the architecture, and coordinate the functional characteristics, non-functional characteristics and architecture with each other on the generated matrix. Functional characteristics Software design support program for executing the expanded procedure for re-use components designed based on the functional properties.