WO2005124541A1 - ソフトウエアライフサイクル管理方法およびソフトウエアライフサイクル管理装置 - Google Patents

ソフトウエアライフサイクル管理方法およびソフトウエアライフサイクル管理装置 Download PDF

Info

Publication number
WO2005124541A1
WO2005124541A1 PCT/JP2005/010355 JP2005010355W WO2005124541A1 WO 2005124541 A1 WO2005124541 A1 WO 2005124541A1 JP 2005010355 W JP2005010355 W JP 2005010355W WO 2005124541 A1 WO2005124541 A1 WO 2005124541A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
space
life cycle
abstract
cycle management
Prior art date
Application number
PCT/JP2005/010355
Other languages
English (en)
French (fr)
Inventor
Toshiyasu Kunii
Original Assignee
Kanazawa Institute Of Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kanazawa Institute Of Technology filed Critical Kanazawa Institute Of Technology
Publication of WO2005124541A1 publication Critical patent/WO2005124541A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design

Definitions

  • the present invention relates to a software life cycle management technology, and in particular, to a software life cycle management device and a software life cycle management device capable of maintaining data consistency between a plurality of different object sets, determining an interface, and performing other processing. About the method.
  • Software life cycle management consists of requirements analysis' specifications, design, implementation, testing, operation, and maintenance. If the initial requirements analysis misses or misinterprets the customer's requirements, the customer's requirements will not be correctly reflected in subsequent system design and implementation. As a result, it takes a great deal of time and effort to maintain software, such as improving programs to correct defects found during the testing and operation stages, and redesigning the system in the case of large-scale changes. In the worst case, software that cannot be maintained may be abandoned, and development will be restarted from the beginning. As described above, if time and effort are not spent on requirements analysis in the initial stage of the software development process, costs are required in the maintenance stage, and the total cost is increased when the development process is viewed as a whole.
  • the waterfall model is a linear development model, and one stage must be completed before starting the next stage, and it is not expected to repeat over multiple stages.
  • the waterfall model requires that all required specifications be stipulated in the first stage and cannot address uncertainties. Even if the customer's requirements are changed after the specification is determined or the program is designed, the waterfall model is new and cannot respond flexibly to the requirements. Normally, software is developed through many iterations through trial and error, so a linear development model that does not assume repetition is almost unrealistic.
  • Information system construction is moving at an accelerating rate from a single large-scale site to a multi-distributed large-scale site, as typically seen in an integrated system associated with the integration of a major bank, for example.
  • an engineering model as a basic framework to deal with this is lacking. The reason for this is that, because the integration method is lacking at the model level, the engineers in charge of each site construction individually devise and design and build modules. For this reason, module group specifications naturally differ for each site.
  • the number of reconstructed systems will increase exponentially by the combination of the number of force modules that can be reconstructed, resulting in a so-called “development man-hour explosion”.
  • the specifications of the modules are not disclosed due to corporate confidentiality.
  • the interface creation information between the modules is disclosed, the number of interfaces increases exponentially depending on the combination, so that the appearance of “development explosion” becomes more remarkable.
  • Non-Patent Document 1 Shari 'Lawrence' Prigar, Translated by Taisuke Horiuchi, “Software Engineering Theory and Practice", First Edition, Pearson ' Education, November 2001
  • Non-Patent Document 2 Philip A. Laplante and Colin J. Neill, "The Demise of the Waterfall M odel Is Imminent "and Other Urban Myths, ACM QUEUE (Feb. 2004), Vol.1, No.10, pp.10- 15.
  • 2Z3 is said to be a maintenance cost
  • maintenance is a major cost factor for companies that have introduced the system.
  • the cost of making changes to the software is relatively low if the changes are made at the stage of determining the required specifications or at the stage of designing the system or program, but if the changes have been made since the software was shipped and operated, The costs are enormous. Therefore, it is necessary to find the required specifications and design defects at the earliest possible stage, and to reduce changes after operation.
  • changes during the operation and maintenance stages even if only a part of the change, may affect other software parts, and the change is a complex and delicate operation.
  • the present invention has been made in view of the above background, and an object of the present invention is to guarantee the interoperability of software components as a linear model to support automation of software development, testing, and maintenance. It is to provide software life cycle management technology that can be used.
  • One embodiment of the present invention relates to a software life cycle management method.
  • This method uses an incrementally modular abstract hierarchical model that guarantees linear interoperability between sets of software components, and extends the life of the software development process from the test process to the maintenance process. Manage the cycle consistently.
  • the "software component” is a component constituting software automatically generated by the present apparatus, and includes data used by the software, a program constituting the software, and the like.
  • Another embodiment of the present invention relates to a software life cycle management device.
  • This equipment has software development function block, test function block, and maintenance function block using an incrementally modular abstract hierarchical model that guarantees linear interoperability between sets of software components. Cycles are managed consistently based on the abstract hierarchy model.
  • the equivalence relation is defined between a plurality of software component sets, and the equivalence relation is inherited as an invariant between the abstract hierarchies, and the software hierarchies are gradually set in each abstract hierarchy.
  • each abstract layer is modularized, it is possible to incrementally change the design while moving up and down the abstract layer even if software components are added, deleted or modified.
  • the software component set can be transitioned between the state before the change and the state after the change, maintaining mathematical consistency.
  • this device can support development processes such as software componentization, reuse, and debugging.
  • software testing a problem discovered by testing whether or not the software generated by the development process conforms to the detailed specification in each abstract layer is tested.
  • the development process can be repeated by returning to any of the abstract hierarchies, and efficient test processes can be supported using the abstract hierarchies.
  • software maintenance if there is a need to modify or extend the function of the running software, the development process is repeated by returning to the abstract layer at which the modification or function is to be extended. An efficient maintenance process can be supported.
  • FIG. 1 is a diagram illustrating a state in which an adhesion space is generated from two disjoint phase spaces.
  • FIG. 2 is a diagram illustrating a state in which a topological space between a customer and a trading company is bonded.
  • FIG. 3 is a diagram illustrating a state in which a phase space between a seat and a support portion is bonded.
  • FIG. 4 is a configuration diagram of a software development support device according to an embodiment.
  • FIG. 5 is a configuration diagram of an adhesion space level processing block in FIG. 4.
  • FIG. 6 is a configuration diagram of a cell space level processing block of FIG. 4.
  • FIG. 7 is a configuration diagram of an expression level processing block of FIG. 4.
  • FIG. 8 is a diagram illustrating a state in which two phase spaces are bonded by the bonded space level processing block in FIG. 5 to generate a bonded space.
  • FIG. 9 is a diagram illustrating a cell structure of an object.
  • FIG. 10 is a diagram illustrating a cell structure of an object.
  • FIG. 11 From the expression level processing block of FIG. 7, the inconsistency at the expression level is adjusted. It is a figure explaining a child.
  • FIG. 12 is a diagram illustrating how the mismatch at the expression level is adjusted based on the expression level processing block shown in FIG. 7.
  • FIG. 13 is a diagram illustrating how the mismatch at the expression level is adjusted based on the expression level processing block shown in FIG. 7.
  • FIG. 14 is a diagram illustrating how two programs are integrated.
  • FIG. 15 is a diagram illustrating an input / output interface of two modules associated by an adhesive map.
  • FIG. 16 is a diagram illustrating how a program module is updated to a new version.
  • FIG. 17 is a diagram illustrating how two program modules are combined.
  • FIG. 18 is a diagram for explaining how data is shared between two program modules
  • FIG. 19 is a diagram illustrating how two program modules are combined.
  • FIG. 20 is a configuration diagram of a software life cycle management device according to an embodiment.
  • a cyber world by defining a collection of objects to be built in cyber space. To be able to perform automated operations on such collections using a computer as an intelligent machine, each collection must be a "set". Because computers are also forces that are constructed as set-theoretic machines.
  • the computer Given the sets X and Y, the computer computes the union XUY, the product or intersection ⁇ ⁇ ⁇ , the difference X—Y (also written as x ⁇ y), the negation, Perform a set-theoretic operation like X.
  • a cyberspace designed in this way is generally called a topological (X, T) space. Where ⁇ 2 ⁇ .
  • the design of the phase space is automated according to the following specifications.
  • T be the phase (topology) t of the phase space (X, T).
  • T1 is weaker or smaller than T2.
  • T2 is said to be stronger or larger than T1.
  • T2 may be finer than T1, or Tl may be coarser than T2.
  • the strongest phase is the discrete phase, or width set, and the weakest phase is the empty set ⁇ .
  • X instead of (X, T) to represent the phase space, unless ambiguity arises.
  • F _1 (B), where B is open, is also open at X.
  • R has better reflectivity, symmetry, and transitivity, R is called an equivalence relation, and is denoted by.
  • class is actually the power of a set, traditionally called class, and it is difficult to change it now.
  • the set XZ ⁇ of all equivalence classes is called the quotient space or the identification space of X.
  • a set of all elements a that are equivalent to a for an element a of a certain X can be considered.
  • This subset of X is an equivalence class with a as the representative element and is denoted as [a].
  • the equivalence classes whose representative element is the same set. In other words, equivalence classes do not depend on how the representative element is taken.
  • Each equivalence class is not empty because the equivalence class satisfies the reflection rule, symmetry rule, and transitivity rule.
  • A belongs to the equivalence class of a, and different equivalence classes have no common element. Thus, when all equivalence classes are collected, they do not intersect each other and the union of the whole is equal to X. That is, the set X is divided into disjoint unions of equivalence classes. This direct sum division is referred to as a classification t ⁇ ⁇ ⁇ ⁇ regarding the equivalence relation R of the set X, and the set of all equivalence classes is referred to as a quotient set by the equivalence relation of the set X. A quotient whose topology is defined is called a quotient space as described above.
  • the congruence relation is an equivalence relation, and the entire set of figures is divided as a quotient space into a direct sum of a subset of congruent figure powers.
  • the similarity relation is also an equivalence relation, and the entire set of figures is defined as a quotient space. Is divided into direct sums of subsets. Congruence and similarity are examples of affine transformations.
  • the symmetry relation in group theory divides the whole set of figures into a quotient space into a direct sum of a subset of symmetric drawing forces.
  • a set having a partially ordered relation is called a partially ordered set, and the initial is often referred to as a poset.
  • a set is said to be comparable if it is one of the two elements x, y force, SxSy force, or ySx.
  • a partially ordered set in which any two elements can be compared is called a totally ordered set.
  • the relationship between electronic transactions is a semi-order relationship because the relationship between the seller and the buyer is asymmetric, does not satisfy the symmetry rule, and satisfies the antisymmetric rule.
  • the relationship of being an electronic product is symmetric and equivalent since the electronic product for the seller is also the electronic product for the buyer.
  • Strength can be defined for equivalence relations. Two equivalence relations in one set X, R and S! /, And when xRy ⁇ xSy, R is stronger than S! ⁇ , and S is more than R than 3 ⁇ 4 ⁇ ⁇ and! ⁇ ⁇ .
  • the classification by R is more detailed than the classification by S, and the classification by S is coarser than the classification by R.
  • the strongest equivalence relation is an equivalence relation of "the same thing", and the weakest equivalence relation is an equivalence relation that any two elements of X are equivalent.
  • X be the topological space.
  • a quotient map (quotient map), which maps each point xEX to an equivalence class ⁇ - ⁇ -, which is a subset that contains X, which is a surjective and continuous mapping of f ).
  • X ° is open f _1 (X °)
  • ye A is open at X (this means f is continuous)
  • quotient space is a character obtained by equating each element, the equivalence class xZ to EXZ ⁇ , with the point xex included in xZ ⁇ .
  • FIG. 1 is a diagram illustrating a state in which a bonding space is generated from two mutually prime phase spaces X and ⁇ .
  • the bonding map f is a continuous map where f: Y ⁇ X. However, it is Y CY. In this way,
  • the identity map g in this case is
  • VxEX, i (x) x
  • Restriction (r) is an identity map on X that satisfies r: X ⁇ A 1: a continuous etaste of A ⁇ A
  • f is homotopic to g.
  • Homotoby is a continuous mapping extension
  • phase spaces X and Y are homomotopically equivalent.
  • the homotibi type is the same.
  • the two functions f and h are f: X ⁇ Y and h: Y ⁇ X,
  • 1 and 1 are identity maps, that is, 1: ⁇ ⁇ ⁇ and 1: ⁇ ⁇ ⁇ .
  • Homotoby equivalence is also an example of an equivalence relationship, but homotopy equivalence is a broader concept than topology equivalence.
  • Homotoby equivalence can identify changes in information that, after a change, are no longer topologically equivalent. Information is changed by various operations and processes, and the operations and processes are specified by homotoby, and changes in information are verified by homotopic equivalents.
  • phototopic equivalence is more abstract than set-theoretic equivalence. The reason is that when a given set is changed by adding or deleting elements, the set can be made homotoby equivalent by preserving the operation procedure of addition or deletion and the added or deleted elements.
  • a cell is a topological space X that is topologically equivalent (ie, in-phase) to a closed sphere (called a closed n-cell) of any dimension (eg, n dimensions, where n is a natural number).
  • a finite or infinite sequence ⁇ X p IX P c X) pez of a cell X p, which is a subspace of X, indexed by an integer set Z can be constructed. This is called filtration, and satisfies the following conditions.
  • C ⁇ XIX P cx, p EZ ⁇ cell decomposition of the phase space X (cell decomposition), or phase space X, that division into subspace X P is a closed cell (partition).
  • (X, C) is called CW-complex.
  • the cell space can be turned into a reusable resource.
  • Such stored and shared information is called a cellular database, and the system that manages the cell database is called a cellular database management system.
  • X CX is a subspace whose elements are 0-dimensional cells of X
  • X P is made from X P_ 1 as follows. That is, XP is a bijective and continuous mapping called an adhesive map.
  • X p is a direct sum
  • X P is the quotient space (quotient space) or equalization space (identification space), [Number 34]
  • mapping ⁇ is a cell
  • FIG. 3 is an example of an adhesive map of FIG.
  • the filtration space is a homotopically equivalent space to the filtration.
  • ⁇ X P_e ⁇ ... ⁇ together is called CW-space.
  • CW-complex As a cell complex, as described above, this is called a CW-complex.
  • the CW space is diffeomorphic, it is equivalent to a manifold space.
  • the cell representation is designed.
  • the expression format such as the data type and the number of digits of the attribute of the object is detailed. If there is an inconsistency in the expression form of the attribute of the object, processing is performed to match the expression form to the acceptable representation (Admissible Representation). For example, there is a difference in the data type or the number of digits in the inconsistency in the representation format of the object attribute, and the difference can be resolved by data type conversion or digit number conversion.
  • the view ie, the range that the user can see
  • the range that the user can refer to must be limited for security reasons. Therefore, in the view design, a subset outside the object that can be referred to for the user and a view that restricts the attributes of the viewable object are determined.
  • a target to be set to the same value for a specific element of a plurality of object sets is selected.
  • a phase is defined in the outer object set, and an equivalence relation is defined in the topological space, so that the plurality of outer object sets are designed as a bonding space that is a direct sum of the equivalent classes. Furthermore, by decomposing cells into equivalent cells and other cells in the cell space, the equivalence relation is inherited up to the cell space level.
  • the equivalence relation is inherited up to the expression level by defining the expression form of the cell based on the acceptance expression, and the equivalence relation is inherited up to the pure level by defining the user's view at the end.
  • An object can be made equivalent at the expression level by providing a reception expression level to define the reception expression as one instance of the expression level.
  • S is called covering of set X.
  • the “business operation integration decision” is based on n incremental and modular abstract hierarchies. This is equivalent to the decision to make a set covering.
  • the work may be from different institutions.
  • the n sets generally have overlap. For example, the same employee may participate in multiple tasks.
  • Business integration is implemented by inheriting the coverage of the n sets between the incrementally modular abstract layers. In other words, the generation of business coverage at each of the homotby level, the topological space level, the adhesion space level, the cell space level, the expression level, and the view level is business integration.
  • the integration and manipulation between the n information systems takes place through the covering all over an incrementally modular abstraction hierarchy.
  • the integration and operation between the n information systems are both linear.
  • the incrementally-modular abstract hierarchy it is possible to realize a linear interoperability by constructing a linear interface called covering between n information systems.
  • phase space in the incrementally modular abstract hierarchical model is not limited to the Hausdorff space, that is, the T phase space.
  • T-phase space separation
  • two different points can be separated by an open set, but the bonding space can be similarly designed even in a T-phase space or a T-phase space where two different points cannot be separated by an open set.
  • the adhesive space abstracts the characteristics common to the influential commercial information systems used by major corporations and public institutions so that they have the same value as the adhesive space! And build a model.
  • the bonding space is a novel information model that can linearly integrate heterogeneous information systems, and greatly contributes to avoiding the combined explosion of the integration work.
  • the above incrementally modular abstract hierarchy is used for the automation of linear interface generation after linear integration at the glue space level. According to this abstract hierarchy, equivalence relations are inherited down to the lower hierarchy, so that an interface to an existing information system is provided to achieve linear interoperability for executing tasks of an integrated system scale. be able to.
  • a relational database system In a relational database system, a relation is a set of tuples.
  • relay Relations change over time as new tuples are inserted into a session, existing tuples are deleted, or tuple attribute values are modified. For example, consider "Employee (Employee number, name, affiliation, year of joining a company)" as a relay. When a new employee joins the company, the tuple representing that employee must be inserted into the relation “Employee”. On the other hand, when an employee retires, the tuple representing that employee in the relation "employee" must be deleted. In addition, if the assignment destination of an employee changes due to the rearrangement, the value of the attribute “affiliation” must be corrected using the tuple of the employee!
  • relational database changes with time due to insertion, deletion, and correction of tuples.
  • relationships have the unique property of representing the employee's employee number, name, affiliation, and year of entry, which is invariant over time.
  • Relations have a structure that is invariant with respect to time, and this is called a relation schema.
  • the relational database model is based on set theory, it is not possible to define equivalence relations at the level of the topological space. Therefore, if you try to integrate multiple different databases, you will need to redesign the database, such as reassigning IDs, which will cause a problem of man-hour explosion.
  • the equivalence relation defined by the superordinate concept can be reduced to the expression level, so that a plurality of different information systems can be integrated by linear operation. In other words, the interface of each element of the information system can be obtained only by one conversion to the bonding space, and the interoperability is guaranteed by n conversions with n elements, and the number of interfaces is linear.
  • Web information management system typically, the job of a Web information management system is to manage information on the Web, with very close interaction with human perception, through visualizing information using Web graphics. It is.
  • the job of Web graphics is to project various images on graphics screens for human understanding. Humans understand the displayed image by linking the image displayed in the display space to the recognition target in the human recognition space. Often, geometrically accurate representations, even those that are not essential information in the cyber world, can lead to human perception errors due to low-priority geometries.
  • Web Information Management Web graphics must be able to convey important messages on the screen so that humans can recognize them at the speed of the cyber world.
  • Web information modeling of electronic manufacturing with a bonded space model is quite simple. Basically, electronic manufacturing, which is called electronic manufacturing, is modeled as Web information, which is the next source of information about the electronic manufacturing process.
  • step 1 is broken down into the following substeps:
  • a core part of the entire Web technology for electronic manufacturing is the modeling of products and assemblies on the Web as Web information modeling.
  • Figure 3 clearly illustrates the modeling of the most rudimentary assembly using a simple assembly example of a chair with two components: a seat and a support.
  • the components of the product are modularized and replaced to buy higher quality components, to make the most effective upgrades or to repair. It is configured to be possible.
  • FIG. 4 shows a configuration of a software development support device 100 according to the embodiment.
  • the object set storage unit 190 holds a set of objects used for software development. Objects or software components used in software development are data structures and program modules.
  • the software development support device 100 refers to a set of objects stored in the object set storage unit 190.
  • the software development support apparatus 100 may acquire an object set from an information system on the web and refer to the object set without going through the object set storage unit 190.
  • a predetermined correspondence or an interface is defined between two object sets will be described. However, this is more generally described with reference to a plurality of object sets. This is just an example of defining an interface between.
  • the software development support device 100 includes a homotoby level processing block 110, an aggregation level Includes processing block 120, phase space level processing block 130, glue space level processing block 140, cell space level processing block 150, representation level processing block 160, and view level processing block 170, each of which has been described as an incrementally modular abstraction. The processing of each hierarchical level in the hierarchical model is performed.
  • the set level processing block 120 appropriately performs a set operation on a set outside the object stored in the object set storage unit 190, and specifies two outside object sets to be designed.
  • the topological space level processing block 130 specifies the topology for the two object sets identified by the set level processing block 120, so that the two object sets are designed as
  • the two topological spaces X and Y are disjoint, and are the direct or exclusive OR of these topological spaces X and Y.
  • the bonding space level processing block 140 includes an equivalence relation setting unit 44, an equivalence relation holding unit 52, a corresponding element extraction unit 20, a bonding mapping acquisition unit 22, and an equalization as shown in FIG. It includes a mapping acquisition unit 24, a procedure acquisition unit 26, and a procedure recording unit 28.
  • the equivalence relation setting unit 44 accepts an input of the equivalence relation to be applied to the two object sets, as well as automatically generates an equivalence relation based on the input of the user.
  • the equivalence relationship holding unit 52 stores equivalence relationship candidates in advance so that a user can easily set the equivalence relationship. Also, an interface may be provided that allows the user to specify an element of the object set and describe the equivalence relation.
  • the equivalence relation set by the equivalence relation setting unit 44 (hereinafter also referred to as a target equivalence relation) is transmitted to the corresponding element extraction unit 20.
  • the corresponding element extracting unit 20 extracts constituent elements (hereinafter, also referred to as “target elements”) for which a corresponding relation is to be defined in the two object sets, based on the objective equivalence relation.
  • target elements constituent elements
  • the user may designate one of the target elements in one object set, and the corresponding element extracting unit 20 may extract the corresponding target element from the other object set based on the objective equivalence relation.
  • the target element found to correspond by the corresponding element extraction unit 20 has one partial phase A space, that is, an equivalence class is formed, and the adhesion space is formed as an exclusive OR of the equivalence classes according to the theoretical guarantee of the adhesion space model. Since equivalence classes are classified based on invariants specified by equivalence relations, object sets can be classified objectively, and the classification results do not include individual differences among system designers. Also, when one target element is determined, the other target element is determined, so that the correspondence or the number of interfaces becomes linear as described above, and interoperability is guaranteed.
  • the bonding map acquisition unit 22 can specify the bonding map f indicating the correspondence between the target elements. Once the bonding map f is determined, the bonding space
  • the equalization mapping obtaining unit 24 obtains an equalization mapping g, which is a mapping to a bonding space determined by a bonding map f, from the space of the mere exclusive OR of the phase spaces X and Y.
  • the equalization map g can be described by its defining force, the topological spaces X and Y, and the bonding map f.
  • the procedure acquisition unit 26 receives the objective equivalence relationship from the equivalence relationship setting unit 44, the target element from the corresponding element extraction unit 20, the adhesion mapping f from the adhesion mapping acquisition unit 22, the equalization mapping g from the equalization mapping acquisition unit 24.
  • the target element specified by the user and the objective equivalence relation (hereinafter, also referred to as the “attention procedure”) are specified as a homotby, and are specified by a series of processing results.
  • the cell space level processing block 150 includes a joining unit 62, a cell dimension adjusting unit 64, and a correspondence table holding unit 66.
  • the cell space level processing block 150 inherits the specification of a plurality of object sets designed as a bonding space based on the objective equivalence relationship in the bonding space level processing block 140, and specifies the object set at the cell space level. Refine.
  • the cell structure space model is a model in which dimensions are introduced into the bonding space model, and the specification of the object attribute ID and the number of attributes will be refined at the cell space level.
  • the cell joining unit 62 joins two target elements that have a correspondence relationship between the two object sets by the objective equivalence relationship, and expresses the attributes of the objects belonging to each object set by cells.
  • the cell dimension adjusting unit 64 performs a process for eliminating the inconsistency. Inconsistencies in cell dimensions include differences in attribute IDs and number of target elements.
  • the cell dimension adjusting unit 64 adjusts the irregularity of the attribute ID and the number of attributes between the two target elements as needed, and stores a table indicating the attribute correspondence between the two target elements in a correspondence table holding unit. Store in 66.
  • the expression level processing block 160 includes an expression generation unit 72, an expression format adjustment unit 74, and a conversion table holding unit 76.
  • the expression level processing block 160 inherits the specification of the object set refined at the cell space level in the cell space level processing block 150, and further refines the specification of the object set at the expression level.
  • the specifications for the data type and the number of digits of attributes outside the object will be detailed in order to determine the specific expression format of the cell.
  • the expression generation unit 72 generates an expression of an attribute of an object belonging to each of the two object sets.
  • the expression format adjustment unit 74 performs a process for adjusting the inconsistency.
  • Inconsistencies in the expression level include differences in the attribute data type and the number of digits of the target element.
  • the data types include Boolean values, signed integers, positive integers, real numbers, double-precision real numbers, character types, etc., and the representation format adjustment unit 74 converts these data types to align the data types of the target elements. Is also good.
  • the expression format adjustment unit 74 sets the attribute The number of digits may be adjusted and aligned.
  • inconsistencies include differences in units such as metering and money, and one unit system is converted to the other using a conversion formula.
  • the expression format adjustment unit 74 determines the target element of the object set of the topological space X and the target element of the object set of the topological space Y at the expression level. Compare the data type and the number of digits of the attribute, and adjust the data type and the number of digits according to the attribute with higher accuracy. The same applies to the case of adjusting the inconsistency of the expression level of the attribute among the target elements of three or more object sets, and the expression form adjusting unit 74 sets the attribute expression of the corresponding target element of the plurality of object sets. Select the attribute expression with the highest accuracy, and adjust the attribute expression of the target element to the low accuracy! As a result, it is possible to prevent the loss of the original data due to data type conversion, digit skip, etc., after bonding target elements having different precisions.
  • the expression format adjustment unit 74 acts as an expression filter having an accepting expression having the maximum number of characters and digits, and expressions passed through the expression filter have the same value at the expression level.
  • the expression format adjustment unit 74 stores in the conversion table holding unit 76 a table describing a conversion rule when the expression mismatch is adjusted.
  • the view level processing block 170 sets a view suitable for the user, and displays a set of objects on a display or the like using the view.
  • the homotoby level processing block 110 is configured to operate such that when each processing block of the software development support device 100 performs an operation on an object set, the change in the object set caused by the operation becomes homotby equivalent. Guarantee.
  • the homotoby level processing block 110 stores the attention procedure relating to the generation of the adhesive space recorded in the procedure recording unit 28, a table indicating the correspondence of the dimensional mismatch of the cells stored in the correspondence table storage unit 66, and the conversion table storage. Using the table that shows the conversion rules of the cell representation stored in section 76, the object set can be returned to the state before the change by tracing back the change brought to the object set by each operation .
  • the software development support device 100 based on the incremental hierarchical model which is re-modular, guarantees the equivalence relation to the aggregate level, the topological space level, the adhesion space level, the cell space level, the expression level, and the view level.
  • the object set that has passed through the filter is output as an instance whose equivalence relation is mathematically guaranteed.
  • an equivalence relation is set, it is possible to associate between the components of a plurality of object sets. Can always have the same information, and can classify and correlate invariants to the cuts, improving data availability and further improving software development efficiency.
  • a shoe shop X object set 300 and a shoe maker Y object set 200 are designed by the set level processing block 120 and It is stored in the Jetat set storage unit 190. These object sets may be managed as a database.
  • the phase space level processing block 130 designs the object set 300 of the shoe shop X as the phase space X and the object set 200 of the shoe maker Y as the phase space Y. At this point, the two topological spaces X and Y are disjoint.
  • the bonding space level processing block 140 refers to the object set 300 of the use shop X stored in the object set storage unit 190 as the topological space X, and refers to the object set 200 of the shoe maker Y as the topological space Y. Based on the equivalence relation, the two topological spaces X and Y force also generate the adhesive space. FIG. 8 shows how the two phase spaces are bonded by the bonding space level processing block 140.
  • V a shoe shop X purchases specific athletic shoes Y manufactured by a shoe manufacturer Y.
  • the software developer creates this sports shoe Y between the shoe shop X object set and the shoe manufacturer Y object set.
  • the equivalence relation setting unit 44 sets the athletic shoe Y, which is a target element to be noticed, as having an equivalence relation between the shoe space Y and the shoe shop X phase space.
  • the corresponding element extracting unit 20 is a shoe maker corresponding to the athletic shoe Y (reference numeral 202) of the shoe maker Y.
  • the equalization map acquisition unit 24 uses the adhesion map f acquired by the adhesion map acquisition unit 22 to calculate the exclusive OR of the two phase spaces of the case shop X and the shoe maker Y in the adhesion space.
  • the equalization map acquisition unit 24 calculates the equalization map [Equation 46] g: YuX ⁇ YU f X
  • FIG. 9 is a diagram illustrating the cell structure of the athletic shoe 202 in the phase space of the shoe maker Y.
  • Athletic shoes 202 include, as cell attributes, shoe brand name 210, company name 212, type 214, size 216, color 218, material 220, suggested retail price 222, manufacturing cost 224, and country of origin 226.
  • FIG. 10 is a diagram illustrating a cell structure of athletic shoes 302 in the phase space of shoe shop X.
  • the athletic shoe 302 includes, as cell attributes, shoe brand name 310, manufacturer name 312, type 314, size 316, color 318, material 320, selling price 322, and store 324.
  • the cell junction 62 of the cell space level processing block 150 is a cell-level sports shoe 202 in the topological space of the shoe maker Y shown in FIG. 9 and a sports shoe 302 in the topological space of the shoe shop X shown in FIG. ,
  • the common attributes are associated with each other. Since the shoe brand names 210 and 310, types 214 and 314, sizes 216 and 316, colors 218 and 318, and materials 220 and 320 have the same attribute name, they are associated as common attributes.
  • the company name 212 of the athletic shoe 202 of the shoe maker Y and the manufacturer name 312 of the athletic shoe 302 of the shoe shop X are the same element, although their attribute names are different. Therefore, the cell dimension adjusting unit 64 of the cell space level processing block 150 associates the attribute name of the shoe maker Y with the attribute name of the use shop X and unifies the attribute name in the joint cell with the “maker name”. The inconsistency is adjusted by this, and a table that describes the relationship that associates the “company name” of the shoe maker Y with the “manufacturer name” of the shoe shop X is stored in the corresponding table storage unit 66.
  • the first topology when associating attributes between two target elements, if the attribute a exists in the first topology space and the corresponding attribute does not exist in the second topology space, the first topology The ability to process assuming that there is no attribute that can be associated with the attribute a of the space, or the process of adding the empty attribute b in the second phase space and associating it with the attribute a of the first phase space Do.
  • the cell dimension adjusting unit 64 treats the country of origin 226 of the shoe maker Y's athletic shoes 202 as having no attribute to be associated, while the shoe shop X's athletic shoes 302 and the dealer 324 of the athletic shoes 302 Adds the empty attribute to the sports shoe 202 of the shoe maker Y, associates it with the store 324 of the sports shoe 302 of the shoe shop X, and adjusts the inconsistency regarding the number of attributes.
  • Another example of adjusting the number of attributes is when one topology space has one attribute "name” and the other topology space has two attributes "last name” and “first name”. However, since both are substantially the same attribute, the cell dimension adjusting unit 64 associates one attribute “name” with two attributes “last name” and “first name”, The mismatch of the number of attributes can be adjusted.
  • FIGS. 11A to 11C are diagrams for explaining the adjustment of mismatch at the expression level.
  • the company name 212 on the shoe manufacturer Y side is represented by an M-digit character string as shown in FIG. 11 (a).
  • the manufacturer name 312 on the shoe shop X side is represented by an L-digit character string as shown in FIG. 11 (b).
  • L ⁇ M.
  • the expression format adjustment unit 74 of the expression level processing block 70 determines the expression format of the manufacturer name 412, which is an attribute of the junction cell, in accordance with the large number of M digits, as shown in FIG. 11 (c). Good.
  • the expression form adjusting unit 74 adjusts the inconsistency of the expression form of the attribute of the target element by using a predetermined receptive expression level as a filter.
  • FIGS. 12 (a) to 12 (d) are also diagrams illustrating adjustment of mismatch at the expression level.
  • the size 216 on the shoe manufacturer Y side is represented by a real number in inches.
  • the size 316 on the shoe shop X side is represented by a real value as a unit.
  • the expression format adjustment unit 74 of the expression level processing block 160 As shown in FIG. Is expressed in cm and the attribute value of size 316 on the shoe shop X side is used. At this time, the expression format adjustment unit 74 stores the conversion formula 516 shown in FIG. 12D in the conversion table holding unit 76, and maintains the compatibility of the attribute values. Thus, matching with any one of the unit systems is an example of the acceptable expression level.
  • FIGS. 13 (a) to 13 (d) are also diagrams illustrating adjustment of mismatch at the expression level.
  • the color 218 on the shoe manufacturer Y side is represented by an integer value as shown in FIG.
  • the color 318 on the case shop X side is represented by a character string as shown in FIG. 13 (b).
  • shoe maker Y uses a numbering system to identify the colors of shoes in detail
  • shoe shop X uses shoes such as “navy blue” and “purple” that customers can easily understand. These are the powers described by name. This difference is due to the design intentions of the designers and customer needs in the systems of shoe manufacturer Y and shoe shop X.
  • the expression format adjustment unit 74 of the expression level processing block 160 uses the expression format of the color 418 as a character string.
  • the attribute value of the color 318 on the shoe shop X side is used.
  • the expression format adjusting unit 74 converts the conversion rule between the integer value identifying the color on the shoe manufacturer ⁇ side and the character string identifying the color on the shoe shop X side.
  • the conversion table shown is created and stored in the conversion table holding unit 76 to maintain the compatibility of the attribute values. Conversion to a character string expression in this way is also an example of the acceptable expression level.
  • the software developer specifies an athletic shoe having an equivalence relationship between the shoe shop X and the shoe manufacturer ⁇ .
  • the equivalence relationship between the shoe shop X and the plurality of shoe manufacturers ⁇ May be specified. For example, based on the equivalence relationship of "Shoes made of leather", the correspondence between the topological space of shoe shop X and the topological spaces of multiple shoe manufacturers Yl, ⁇ 2, ..., ⁇
  • the constituent elements may be extracted, a bonding space may be generated, and data design of the object may be performed.
  • a program is considered, and a procedure of developing software based on a plurality of programs by the software development support device 100 according to the present embodiment will be described.
  • FIGS. 14 (a) and 14 (b) are diagrams illustrating how two programs X and Y are integrated. It is assumed that these programs have different program configurations, for example, because the developers of power programs that perform image processing are different. Each of these programs has a function of encoding and decoding images, and for example, can encode and decode images of commodities sold in electronic commerce.
  • the set level processing block 120 designs programs X and ⁇ ⁇ composed of a plurality of modules as a set
  • the phase space level processing block 130 designs programs X and ⁇ as phase space.
  • the equivalence relation setting unit 44 of the adhesion space level processing block 140 provides two equivalents, "having an encoding function" and “having a decoding processing function", for the modules constituting the programs X and ⁇ . Set the relationship.
  • the corresponding element extraction unit 20 specifies the module corresponding to the program X and ⁇ based on the two equivalence relations set by the equivalence relation setting unit 44, and the bonding map acquisition unit 22 performs the correspondence based on each equivalence relation. Get the glue maps f, f giving the relationship
  • phase space of the program Y is separated from the module Y having the encoding function by the compression space.
  • phase space of the program X is divided into f (Y) corresponding to ⁇ in a module having a coding function, and f (Y) corresponding to ⁇ in a module having a compression processing.
  • the equalization map acquisition unit 24 calculates the sum of the two phase spaces of the programs X and Y shown in Fig. 14 (a) by using the adhesive space shown in Fig. 14 (b).
  • FIGS. 15 (a) and 15 (b) are diagrams illustrating input / output interfaces of two modules A and B associated with each other by an adhesive mapping.
  • the variables used for the input of module A are the integer type a and b, and the variable used for the output is the real type c.
  • the two variables used for the input of module B are real s and t, and the variable used for the output is real u.
  • the cell dimension adjusting unit 64 of the cell space level processing block 150 includes two modules A and Adjust so that the names of the input variables and output variables of B can correspond.
  • the cell dimension adjusting unit 64 can correspond the number of input variables and output variables of the two modules 8 and B. Adjust as follows.
  • the expression format adjustment unit 74 of the expression level processing block 160 adjusts the data types of the input variables and output variables of the two modules A and B if there are differences. Since the input variables of module A are of integer type and the input variables of module B are of real type, for example, the input variable of module A is converted to real type. If the variable is of a character type, the expression format adjustment unit 74 adjusts the number of digits of the character string.
  • FIGS. 16 (a) and 16 (b) are diagrams for explaining how a program module is updated to a new version. As shown in Figure 16 (a), the new version of module A and the old version
  • module A Each may be designed by a different developer. Same
  • the new version of module A I can respond. Also, the input variables s and t of the new version of module A are
  • the software development support apparatus 100 replaces the old version of the module A with the new version of the old module A as shown in FIG. 16 (b). And can be updated.
  • the support device 100 can also convert the new version of module A back to the old version of module A if necessary.
  • FIGS. 17 (a) and 17 (b) are diagrams for explaining how two program modules are combined. As shown in Fig. 17 (a), module A has two submodules A and A, and module A
  • File B has two submodules B and B. Sub-module of module B
  • Module B is associated with module A submodule A. Accordingly, the input variable s of the submodule B and the input variable a of the submodule A are associated with each other.
  • the sub-module B of module B is identified with the sub-module A of module A by the adhesive mapping determined by the equivalence relation, so that the two modules A and B are combined. And one program is generated. At this time, the data types and the number of digits of the input and output variables of submodule B and submodule A, which are associated with each other by the adhesive mapping, are adjusted. Since the software development supporting apparatus 100 synthesizes the modules so that they have the same homotoby value, the synthesized program power and the original modules A and B can be separated and extracted as necessary.
  • the software development support device 100 can synthesize a plurality of modules based on equivalence relations, or can extract a synthesized program power module, and realize software componentization. And increase reusability.
  • FIGS. 18 (a) and 18 (b) are diagrams for explaining how data is shared between two program modules.
  • a module that inputs two variables a and b and outputs a variable c There is a module A that inputs two variables s and t and outputs a variable u, and the input variable s of module B and the input variable a of module A are associated by an equivalence relation, and It is assumed that there is no correspondence between variables other than.
  • the input variable s of module B is identified with the input variable a of module A by the adhesive mapping determined by the equivalence relation, so that the two modules A and B One of the input variables is shared.
  • the software development support apparatus 100 can share data associated as equivalent classes between program modules, and can improve the usability of data.
  • FIGS. 19A and 19B are diagrams illustrating a state where two program modules are combined. As shown in Fig. 19 (a), there are a module A that inputs two variables a and b and outputs a variable c, and a module B that inputs two variables s and t and outputs a variable u. Assume that the output variable u of B and the input variable a of module A are associated by an equivalence relationship, and that there is no correspondence between the other variables.
  • the output variable s of module B is identified with the input variable a of module A by the adhesive mapping determined by the equivalence relation, so that module B and module A are in this order.
  • the data type and the number of digits are adjusted between the output variables of module B and the input variables of module A. Since the binding of this program is performed so that the homotoby becomes equivalent, the module A and the module B can be separated by releasing the binding if necessary.
  • the software development support device 100 can combine or separate a plurality of program modules based on the equivalence relation, and can increase the usability of the program modules.
  • the development process such as synthesis, replacement, and connection of software components can be performed by a linear operation based on the equivalence relation, so that the number of software components is reduced. Even if it increases, software can be developed efficiently without explosion of development man-hours.
  • an input / output interface is taken as an example of an attribute that characterizes the specification of a program module, and the inconsistency of the input / output interface dimensions and expression format is adjusted between the corresponding program modules.
  • this is just an example of an attribute. Absent.
  • a variable referred to by the program module may be considered. In such a case, the inconsistencies in the dimensions and expression forms of the reference variables are adjusted between the corresponding program modules.
  • a function used by a program module may be considered as an attribute. In this case, inconsistencies in the dimensions of the functions, that is, the function names and the number of functions, are adjusted between the corresponding program modules. Further, the inconsistency of the dimension or expression form of the argument or return value of the function may be adjusted.
  • the view level processing block 170 of the software development support device 100 may design a different view for each software developer. For example, to enable advanced software developers to change the design of internal variables of a program module, set up a view that allows data manipulation inside the program module. On the other hand, a view that does not allow data manipulation inside the program module is set so that the beginner software developer can only change the design of the external interface of the program module. In this way, the views may be different depending on the level of the programming experience and skills of the developer. Also, when multiple developers jointly develop software, the view may be different for each developer so that the design can be changed only for the program area for which each developer is responsible. When the software development support device 100 is used in a maintenance process as described later, the view level processing block 170 may design a different view for each software maintainer.
  • Software development activities include requirements analysis, system design, program design, program implementation, unit and integration testing, system testing, acceptance testing, and operation and maintenance.These activities are managed as a life cycle. .
  • Requirements analysis, system design, program design, and program implementation are the software development processes. In the development process, the generated software program modules! / Unit test is performed, then a system test is performed on the functional aspects of the entire system, and finally an acceptance test is performed at the time of system shipment. This is the test process. The system that passes the acceptance test is operated and the system is maintained during operation. This is the maintenance process.
  • the software life cycle management device 600 shown in FIG. After that, it manages the software life cycle up to the maintenance process.
  • the development function block 610 has the functions of the software development support device 100 described above, and inherits the equivalence relation of the software component set as an invariant between the abstract layers, and defines the specifications that the software component set must satisfy. By incrementally refining each abstract layer, software that satisfies given requirements is automatically generated.
  • the development function block 610 the required analysis capability of the software is also executed up to the system design, the program design, and the program implementation, and the developed software is stored in the software storage unit 640.
  • the software storage unit 640 holds all programs in the required specifications, development, test, and maintenance processes.
  • test function block 620 tests whether or not the software generated by the development function block 610 conforms to the detailed specification in each abstract layer.
  • the requirements are modified in the abstract hierarchy, and the development function block 610 incrementally details the specifications to be satisfied by the set of software components for each abstract hierarchy, starting from the abstract hierarchy in which the requirements are modified.
  • the development function block 610 If the 20 finds a defect in the required specification and corrects it, the development function block 610 returns to the upper layer such as the topological space level and the adhesive space level of the extracted hierarchical model, and starts design details from that layer. Redo the problem to eliminate the problem. In addition, if a failure is found in the number of function arguments or the data type of a variable in the test function block 620 program implementation, the development function block 610 determines the level of the abstract hierarchical model, such as the cell space level or expression level. Resolve the defect by refining the design from the lower hierarchy. Even when the work is re-started from any layer, the software development support device 100 based on the incrementally modular abstract layer can reconfigure the software by linear operation under new requirements.
  • the maintenance function block 630 changes the requirement conditions in the abstract layer where the correction or function extension needs to be reflected when the operating software requires modification or function extension, and executes the development function block. 610 starts at the abstract hierarchy where the requirements have changed, The specification to be satisfied by the software component set is incrementally detailed again for each abstract hierarchy.
  • Software maintenance includes corrective maintenance and preventive maintenance, which are performed to correct or cope with system failures, and to extend system functions. These include improvement maintenance and adaptive maintenance.
  • Corrective maintenance is to find the cause of a failure and to make necessary corrections to the software when a failure occurs in the current system. Corrective maintenance is the work of correcting residual defects in software, and generally does not change specifications. Corrective maintenance using the abstract hierarchical model is performed by adjusting the requirements at relatively lower levels such as the cell space level and the expression level.
  • Preventive maintenance is the modification or alteration of certain aspects of a system in order to discover potential potential failures and prevent system failures, even though they have not actually failed. It can be performed using an abstract hierarchical model as in the case of correction maintenance.
  • Improvement maintenance refers to making software changes to improve certain functions and performance of the system, rather than changing the software to avoid failures. Improvement maintenance involves a change in software specifications. In the improvement and maintenance using the abstract layer model, the software is redesigned while adjusting the requirements at relatively higher layers such as the topological space level and the adhesive space level, and then passing through the abstract layers toward lower layers. It is done by doing.
  • Adaptive maintenance involves changing the software in response to changes such as technological advances in hardware and software. Adaptive maintenance is about making changes to adapt to evolving systems rather than addressing obstacles. Adaptive maintenance can also be performed using the extraction hierarchy model, as with other maintenance.
  • the software maintenance process consists of analyzing new requirements, evaluating system and program designs, reviewing code, and making corrections as necessary. Including activities in common with Just as the development process and the test process are performed using the abstract hierarchical model, the maintenance process is also performed in the abstract hierarchical model.
  • the system can be efficiently used by effectively using the tools, and the burden of maintenance can be reduced.
  • defect repair has a ripple effect that causes another defect repair. Maintenance modifications can affect other parts of the system and create new obstacles.
  • software development depends on the developer, so it is difficult to accurately predict the effects of maintenance even if the specifications created by the developer are carefully reviewed.
  • software life cycle management device 600 of the present embodiment software development is performed using the abstract hierarchical model, and the developer-dependent design elements are eliminated.
  • the software life cycle management device 600 of the present embodiment by using the extraction hierarchy model, even if a change in the request occurs at the maintenance stage, the equivalence relation is obtained based on the required specification. It is possible to determine the specification and to inherit the equivalence relation as an invariant up to the design and implementation levels, to achieve detailed specification and concrete specification, and to respond flexibly and efficiently to changes.
  • the abstract hierarchical model operations on software in the maintenance process are guaranteed linear interoperability in the same way as operations in the development process. To delete It comes out.
  • the software life cycle management device 600 of the present embodiment has It does not depend on the cycle model, nor does it apply based on any life cycle model. However, use of the software life cycle management device 600 according to the present embodiment in a form adapted to the life cycle model! /.
  • a major advantage of the software life cycle management device 600 of the present embodiment is that the use of an incrementally modular abstract hierarchy model guarantees consistency by inheriting equivalence relations between software component sets between abstract hierarchies as invariants. In addition, it guarantees linear integration and linear operation of software component sets, and consistently manages the life cycle from software development testing to maintenance.
  • the present invention can be applied to the field of software life cycle management.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

　位相空間レベル処理ブロック１３０は、オブジェクト集合記憶部１９０に格納されたプログラムを位相空間として設計する。接着空間レベル処理ブロック１４０は、複数のプログラムの上に同値関係を設定し、同値関係で対応づけられたプログラムモジュールを接着した接着空間を設計する。セル空間レベル処理ブロック１５０は、モジュールの属性をセルで表現し、セルの次元を設計し、表現レベル処理ブロック１６０は、セルの表現を設計する。ビューレベル処理ブロック１７０は、ソフトウエア開発者もしくは保守者に対するビューを設計する。ホモトピーレベル処理ブロック１１０は、ソフトウエアの開発、試験、および保守に伴う操作によって生じるプログラムの変化をホモトピーとして設計する。

Description

明 細 書
ソフトウェアライフサイクル管理方法およびソフトウェアライフサイクル管理 装置
技術分野
[0001] この発明はソフトウェアライフサイクル管理技術、とくに、複数の異なるオブジェクト 集合間でデータの一貫性維持、インタフェイスの確定その他の処理をなすことのでき るソフトウェアライフサイクル管理装置およびソフトウェアライフサイクル管理方法に関 する。
背景技術
[0002] 「ソフトウェア工学」（Software Engineering)という用語は、 1968年の NATO会議で 最初に使われたといわれる。この会議において討議されたソフトウェア設計法、プロ ジェタト管理、技術者教育、ソフトウェアの価格および流通の 4つの項目は、今なお、 ソフトウェア工学の中心課題である (非特許文献 1参照)。
[0003] ソフトウェアライフサイクル管理は、要求分析'仕様、設計、実装、テスト、運用、およ び保守の各段階からなる。最初の要求分析が甘ぐ顧客の要求を取りこぼしたり、取 り違えたりすると、それ以降のシステム設計、実装に顧客の要求が正しく反映されな い。そのため、テストや運用段階で発見された不具合を修正するために、プログラム を改良したり、大規模な変更の場合はシステム設計をやり直すなど、ソフトウェアの保 守に大変な時間と労力がかかる。最悪の場合、保守に耐えられないソフトウェアは廃 棄されることもあり、最初から開発をやり直すことになる。このように、ソフトウェアの開 発プロセスの初期段階において、要求分析に時間と労力を惜しむと、保守段階にお いてコストがかかり、開発プロセスをトータルでみた場合に、全体のコストが肥大する。
[0004] ソフトウェアの伝統的なライフサイクルモデルの一つに、 1970年に提案されたゥォ 一ターフォールモデルがある。ウォーターフォールモデルでは、ソフトウェア製品は、 要求分析から始まり、システム設計、プログラム設計、プログラム実装、単体'結合テ スト、システムテスト、運用、保守に至るまでシーケンシャルに開発されるものと考え、 ソフトウェアの開発のアクティビティをモデル化している。 [0005] ウォーターフォールモデルは、直線的な開発モデルであり、ある段階は次の段階を 開始する前に完了する必要があり、複数の段階にまたがった繰り返しは想定されな い。ウォーターフォールモデルは、最初の段階ですベての要求仕様を明確に定める ことを要求し、不確実性に対応することはできない。顧客の要求が仕様の決定後や プログラムの設計段階で変更されても、ウォーターフォールモデルでは新し 、要求に 柔軟に対応することができない。通常、ソフトウェアは試行錯誤しながら多くの繰り返 しを経て開発されるため、繰り返しを前提としな 、直線的な開発モデルはおよそ現実 的ではない。そのため、ウォーターフォールモデルは今日、非常に大規模なソフトゥ エアの開発モデルとして用いられることはあっても、一般的には利用されていない。こ れらのよく知られたウォーターフォールモデルの限界は、最近米国で行われたソフト ウェアエンジニアリングに関するサーベイにおいても指摘されている（非特許文献 2 参照)。
[0006] 情報システム構築は、たとえば大手銀行の統合に伴う統合システムに典型的にみら れるように、単一大規模サイト向けから、複数分散大規模サイト向けに加速度的に移 行しつつある。ところが、その基盤技術となっている現在のソフトウェア工学、リエンジ ニアリング技術において、これに対応するための基本的枠組みとしてのエンジニアリ ングモデルが欠落している。その理由は、統合方法がモデルレベルで欠如している ために、各サイト構築担当のエンジニアが個々にモジュール群を工夫して設計'構築 している点にある。このために、モジュール群仕様がサイト毎に自ずと異なる。モジュ ール群の仕様が相互に開示されれば、再構築も可能である力 モジュールの数の組 み合わせにより指数関数的に再構築システム数が増え、いわゆる「開発工数爆発」が 生じる。しかも、実際には、企業機密保持上モジュール群の仕様が開示されない場 合のほうが多い。この場合、モジュール間のインタフェイス作成情報が開示されるもの の、インタフェイス数も組み合わせにより指数関数的に増加するので、一層「開発ェ 数爆発」の様相が顕著となる。
非特許文献 1 :シャリ 'ローレンス'プリ一ガー著，堀内泰輔訳， 「ソフトウェア工学 理 論と実践」，初版，株式会社ピアソン 'エデュケーション， 2001年 11月
非特許文献 2 : Philip A. Laplante and Colin J. Neill, "The Demise of the Waterfall M odel Is Imminent" and Other Urban Myths, ACM QUEUE (Feb. 2004), Vol.1, No.10 , pp.10- 15.
発明の開示
発明が解決しょうとする課題
[0007] ソフトウェアの効率的な開発と保守を支援するための理論的基礎となるエンジニア リングモデルが欠如しているために、要求分析からシステム設計、実装、テスト、保守 に至るまでのソフトウェアライフサイクルのスムーズな流れが滞り、ソフトウェア開発が 遅延し、また、運用段階で不測の事態が発生しやすいためリスク管理が難しぐソフト ウェアの保守に力かるコストが増大して 、る。
[0008] 国内外には、リレーショナル 'データべ一ス（RDB)モデル、 ERモデル、タグによる XML、グラフによる UMLなどが研究され応用されている力 大規模分散情報システ ムを構築する理論的基礎としてはモデル的に完全とは 、えず、例えばモジュール間 のインタフェイス仕様力 異なるサイト間で統一的に取り扱える理論体系になっていな い。したがって、前述の「開発工数爆発」は解決できない。
[0009] また、各国において昨今の厳しい経済状況もあり、会社統合が増加の一途をたどつ ているが、異なる情報システム間で整合性をもって情報処理を自在に行えること、す なわち、情報システムのインターオペラピリティが確保されないため、情報システムの 運用と保守の費用が増大して！/ヽる。
[0010] 大規模システムのコストの半分から 2Z3は保守費用であると言われており、保守は システムを導入した企業にとって大きなコスト要因となっている。特に稼働中のシステ ムに不具合が生じた場合、保守は企業の存続に関わる問題となることもあり、大変な リスクを伴う。ソフトウェアに変更を加えるコストは、その変更が要求仕様の決定段階 あるいはシステムやプログラムの設計段階で行われるのであれば、比較的低いが、ソ フトウェアが出荷され、運用されてからの変更の場合、コストはとてつもなく大きくなる 。したがって、できるだけ早い段階で要求仕様や設計の不具合を見つけ、運用後の 変更を少なくする必要がある。また、運用'保守段階での変更は、たとえ一部の変更 であっても、他のソフトウェアの部分に影響を与えることもあり、変更は複雑で慎重を 要する作業となる。ソフトウェアの保守を効率的に行うこと力 ソフトウェアの全体コス トを削減する上できわめて重要である。
[0011] 本発明はこうした背景力 なされたものであり、その目的は、ソフトウェア部品のイン ターオペラピリティを線形モデルとして保証して、ソフトウェアの開発、試験、および保 守の自動化を支援することのできるソフトウェアライフサイクル管理技術を提供するこ とにある。
課題を解決するための手段
[0012] 本発明のある態様はソフトウェアライフサイクル管理方法に関する。この方法は、ソ フトウェア部品集合間の線形インターオペラピリティを保証するインクリメンタリモジュ ラな抽象階層モデルを利用して、ソフトウェアの開発工程カゝら試験工程を経て、保守 工程に至るまでのライフサイクルを一貫して管理する。
[0013] 「ソフトウェア部品」は、本装置により自動生成されるソフトウェアを構成する部品で あり、ソフトウェアで利用されるデータ、ソフトウェアを構成するプログラムなどを含む。
[0014] 本発明の別の態様はソフトウェアライフサイクル管理装置に関する。この装置は、ソ フトウェア部品集合間の線形インターオペラピリティを保証するインクリメンタリモジュ ラな抽象階層モデルを利用した、ソフトウェアの開発機能ブロック、試験機能ブロック 、および保守機能ブロックを備え、ソフトウェアのライフサイクルを前記抽象階層モデ ルにもとづ 、て一貫して管理する。
[0015] この装置によれば、複数のソフトウェア部品集合の間で同値関係を規定し、その同 値関係を不変量として抽象階層間で継承しながら、各抽象階層において段階的にソ フトウェア部品集合の満たすべき仕様を設計することができる。集合レベル、位相空 間レベル、接着空間レベル、セル空間レベル、表現レベル、およびビューレベルを通 して、同値関係が保証され、最終的にソフトウェアが数学的に整合性のある形で生成 される。また、各抽象階層はモジュール化されており、ソフトウェア部品の追加、削除 、および修正などを行っても、抽象階層を上下に行き来しながら、インクリメンタルに 設計変更することができる。さらに、ソフトウェア部品集合に対してなされる操作をホ モトピーとして扱うことにより、ソフトウェア部品集合を変化前の状態と変化後の状態 の間で相互に移行させることができ、数学的な整合性を維持しながら、ソフトウェアの 部品化、再利用、デバッグなどの開発工程を支援することができる。 [0016] この装置によれば、ソフトウェアの試験に関して、開発工程により生成されたソフトゥ エアが各抽象階層にお 、て詳細化された仕様に合致する力否かをテストし、発見さ れた問題に応じていずれかの抽象階層もどって開発工程を繰り返すことができ、抽 象階層を利用して効率的な試験工程を支援することができる。さらに、ソフトウェアの 保守に関して、運用中のソフトウェアに修正もしくは機能拡張の必要があった場合に 、その修正もしくは機能拡張を行うべき抽象階層にもどって開発工程を繰り返すこと により、抽象階層を利用して効率的な保守工程を支援することができる。
[0017] なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システ ム、記録媒体、コンピュータプログラム、データ構造などの間で変換したものもまた、 本発明の態様として有効である。
発明の効果
[0018] 本発明によれば、情報システムのインターオペラピリティを保証し、ソフトウェア開発 、試験、および保守を含むソフトウェアライフサイクルの管理の効率ィ匕を図ることがで きる。
図面の簡単な説明
[0019] [図 1]2つの互いに素である位相空間から接着空間が生成される様子を説明する図 である。
[図 2]顧客と取引会社の位相空間が接着される様子を説明する図である。
[図 3]座席と支持部の位相空間が接着される様子を説明する図である。
[図 4]実施の形態に係るソフトウェア開発支援装置の構成図である。
[図 5]図 4の接着空間レベル処理ブロックの構成図である。
[図 6]図 4のセル空間レベル処理ブロックの構成図である。
[図 7]図 4の表現レベル処理ブロックの構成図である。
[図 8]図 5の接着空間レベル処理ブロックにより、 2つの位相空間が接着されて接着空 間が生成される様子を説明する図である。
[図 9]オブジェクトのセル構造を説明する図である。
[図 10]オブジェクトのセル構造を説明する図である。
[図 11]図 7の表現レベル処理ブロック〖こより、表現レベルでの不整合が調整される様 子を説明する図である。
[図 12]図 7の表現レベル処理ブロック〖こより、表現レベルでの不整合が調整される様 子を説明する図である。
[図 13]図 7の表現レベル処理ブロック〖こより、表現レベルでの不整合が調整される様 子を説明する図である。
[図 14]2つのプログラムが統合される様子を説明する図である。
[図 15]接着写像により対応づけられた 2つのモジュールの入出力インタフェイスを説 明する図である。
[図 16]プログラムモジュールが新しいバージョンに更新される様子を説明する図であ る。
[図 17]2つのプログラムモジュールが合成される様子を説明する図である。
[図 18]2つのプログラムモジュール間でデータが共有される様子を説明する図である
[図 19]2つのプログラムモジュールが結合される様子を説明する図である。
[図 20]実施の形態に係るソフトウェアライフサイクル管理装置の構成図である。
符号の説明
[0020] 20 対応要素抽出部、 22 接着写像取得部、 24 等化写像取得部、 26 手 順取得部、 28 手順記録部、 44 同値関係設定部、 52 同値関係保持部、 6 2 セル接合部、 64 セル次元調整部、 66 対応テーブル保持部、 72 表現生 成部、 74 表現形式調整部、 76 変換テーブル保持部、 100 ソフトウェア開 発支援装置、 110 ホモトビーレベル処理ブロック、 120 集合レベル処理ブロッ ク、 130 位相空間レベル処理ブロック、 140 接着空間レベル処理ブロック、 1 50 セル空間レベル処理ブロック、 160 表現レベル処理ブロック、 170 ビュー レベル処理ブロック、 190 オブジェクト集合記憶部、 600 ソフトウェアライフサイ クル管理装置、 610 開発機能ブロック、 620 試験機能ブロック、 630 保守機 能ブロック、 640 ソフトウェア記憶部。
発明を実施するための最良の形態
[0021] 以下本発明を好適な実施の形態をもとに説明する。まず、本発明者が提唱するイン クリメンタリモジュラな抽象階層（incrementally modular abstraction hierarchy)を説明 し、その後、インクリメンタリモジュラな抽象階層を実装した情報処理装置を説明する
[0022] [1]集合論的設計
まず、サイバースペースに構築すべきオブジェクトの集まりを定義することからサイ バーワールドの設計を始める。そのような集まりに対してインテリジェントマシンとして コンピュータを使った自動操作の実行が可能であるためには、各集まりは「集合 (set) 」でなければならない。なぜなら、コンピュータは集合論的機械として構築されている 力もである。直観的に、集合 Xは、同一のプロパティ P (x)をもったすべてのオブジェ タト Xの集まりである。これを記号で表すなら、 X= {x I P (x) }である。集合に含まれる 任意のオブジェクトを元または要素（element) t 、う。要素をもたな 、集合を空集合 φ という。すべての要素が内部（interior)であるならば、その集合は開集合であるという 。集合 Xと Yが与えられたとき、コンピュータは、和 (union) X U Y、積または共通部分（ intersection) Χ Π Υ、差（difference) X— Y(x\yとも書く）、否定 (negation)，Xのよう な集合論的演算を施す。
[0023] 最初のサイバースペースとして集合 Xからサイバースペースアーキテクチャの設計 を始めるとしょう。未知のサイバースペース Uのすベての要素 uが与えられたとき、もし それらの要素がすべてサイバースペース Xの要素であることが確かめられたならば、 その未知のサイバースペースを Xの部分集合、すなわち Xの部分サイバースペースと 呼び、 と表記する。部分集合であるかどうかは、（Vu) (uEU→uEX)を処理 することで自動的に調べることができる。 Uの閉包（closure)
[数 1]
U
は、 Uを含む Xのすベての閉部分集合の積である。言い換えれば、 Uの閉包は、 Uの 外部（exterior)要素でない Xの要素である。 Xの部分集合 {U | のすベてから なる集合を Xの巾（べき)集合といい、 2Xと表記する。これはまた Xの離散位相（discret e topology)とも呼ばれる。離散位相はサイバースペースを部分サイバースペースから なるものとして設計する上でた 、へん有用である。 [0024] [2]位相幾何学的設計
これから、サイバースペースを Xの（複数の）部分サイバースペースとその重複（over lap)の和として設計する作業に入る。このように設計されるサイバースペースは一般 に位相（トポロジー）空間（X, T)と呼ばれる。ここで Τ 2Χである。位相空間の設計は 次の仕様により自動化される。
1) ΧΕΤかつ φ≡T;
2)任意の添え字の集合 Jに対して、
Vj ej (U £T)→U U≡T;
i j<≡J j
3) u, veT→u nveT
[0025] 上記の設計仕様の 1)は、空集合と全体集合力Tの要素であること、 2)は、 Tの要素 をいくつもってきて和をとつても Tの要素であること、 3)は、 Tの 2つの要素の積（共通 部分)も Tの要素であることを示して 、る。
[0026] Tを位相空間（X, T)の位相（トポロジー） t 、う。 Tl CT2である 2つの位相 T1と T2 が与えられたとき、 T1は T2よりも弱いまたは小さいという。逆に、 T2は T1よりも強い または大きいという。また T2は T1よりも細力ぃ、あるいは Tlは T2よりも粗いということ もある。明らかなように最も強い位相は離散位相すなわち巾集合であり、最も弱い位 相は空集合 Φである。簡単のため、あいまいさが生じないならば、位相空間を表すた めに（X, T)の代わりに Xをしばしば用いる。
[0027] 2つの位相空間（X, T)と (Υ, Τ')が与えられたとき、 V、かにして (X, Τ)と（Υ, Τ')が 同値であるということができるだろうか。コンピュータを使って、それらの空間が位相幾 何学的に同値であることを自動的に検証 (validate)するための基準をここに与える。 2 つの位相空間 (X, T)と (Υ, Τ')は、連続な関数 f : (X, Τ)→(Υ, Τ')が存在し、かつ その逆関数も存在して連続であるならば、トポロジー同値 (topologically equivalent)、 すなわち同相、同位相または位相同形 (homeomorphic)であるという。（X, T)力 (Y, Τ')と同相であることを
[数 2]
(Χ，Τ Υ，丁，） と書く。
[0028] それでは、関数 fの連続性はどのように立証することができる力。最初に、 VB£T', 广 BETであることを調べる。ここで; ΓΒは fによる Bの逆像を意味する。次に、以下が 成り立つことを調べる。
Bが開である f_1(B)もまた Xにおいて開である。
[0029] [3]関数
関数 f :X→Yが与えられたとき、全域関数 (total lunction)と部分関数 (partial foncti on)が存在する。関数 f:X→Yに対して、 VxEX、ョ f(x)であるとき、そしてそのとき に限り、関数 fは全域関数であるという。関数 f:X'→Y I X'2Xを部分関数といい、こ のとき f(x)は必ずしもあらゆる χΕΧに対して存在しているとは限らない。
[0030] 全域関数に対して、 3つの基本的なタイプの関係あるいは写像が存在する。
1.単射 (injectiveまた ίま into)
Vx, y≡X x≠y→f(x)≠f(y)
言い換えれば、
Vx, y≡X f(x)=f(y)→x=y
2.全射 (surjectiveまたは onto)
(VyEY) (ョ xex) [f(x)=y]
3.全単射（bijective)
単射かつ全射であること
[0031] [4]同値関係
集合 X上の任意の 2項関係 R XXXに対して、 Rは、
1) (VxEX) [xRx]ならば、反射性があり、
2) (Vx, y≡X) [xRy→yRx]ならば、対称性があり、
3) (Vx, y, z≡X) [[xRy→yRz]→xRz]ならば、推移性があるという。 1)〜3)の条 件は、それぞれ反射律、対称律、推移律と呼ばれる。
[0032] Rが反射性、対称性、推移性をもっとき、 Rを同値関係 (equivalence relation)と呼び 、〜で表記する。
[0033] χΕΧが与えられたとき、 xZ〜= {yEX:X〜y}で定義される Xの部分集合を Xの同 値類 (equivalent class)と呼ぶ。ここで類 (class)は実際には集合を意味する力 伝統 的に類 (クラス）と呼ばれており、今となっては変更するのは難しい。すべての同値類 の集合 XZ〜を Xの商空間（quotient space)もしくは等化空間（identification space) という。
XZ〜= {x/〜E 2x I x£X} c 2x
推移律より、各 χΕΧ、 χΖ〜≠ φについて、以下が成り立つ。
[数 3]
X 〜 y « X /〜 = y /〜, and
X y <=z> X /〜 门 V /~ = 0
これは集合 Xが空でな 、互いに素の (すなわち共通要素をもたな 、）同値類に分割さ れる (分解されるとも 、う)ことを意味する。
[0034] 一般に、集合 Xの上に同値関係〜が定義されたとき、ある Xの要素 aに対して aに同 値である要素をすベて集めた集合を考えることができる。この Xの部分集合は、 aを代 表要素とする同値類であり、 [a]と表記される。ここで、同値類に含まれる要素のうち どれを取っても、それを代表要素とする同値類は同じ集合になる。すなわち、同値類 は代表要素の取り方によらない。同値類が反射律、対称律、および推移律を満たす ことより、各同値類は空ではなぐ aの同値類には aが属し、相異なる同値類には共通 の要素がない。したがって、同値類をすベて集めると、それらは互いに交わらず、ま た全体の和集合は Xに等しくなる。つまり、集合 Xは同値類の直和（disjoint union)に 分割される。この直和分割を集合 Xの同値関係 Rに関する類別 (classification) t ヽ 、同値類全体の集合を集合 Xの同値関係〜による商集合と呼ぶ。商集合に位相が定 義されたものを上記のように商空間という。
[0035] 簡単な例で説明する。 Xを有理整数の集合とし、 Xの要素 x、 yの関係 Rとして、「x— yが偶数である」を考えると、これは同値関係である。集合 Xをこの同値関係 Rで類別 すれば、集合 Xは、奇数の同値類と偶数の同値類の直和に分割される。
[0036] ユークリッド幾何学において、図形の集合が与えられたとき、合同関係は同値関係 であり、図形の集合全体を、商空間として、合同な図形力 なる部分集合の直和に分 割する。また、相似関係も同値関係であり、図形の集合全体を、商空間として、相似 な図形力 なる部分集合の直和に分割する。合同関係と相似関係はァフィン変換の 例である。群論における対称関係は、図形の集合全体を、商空間として、対称な図 形力 なる部分集合の直和に分割する。
[0037] 電子商取引では、「電子商品であること」は同値関係である力 「電子取引」は半順 序 (partially ordered)関係であることに留意する。集合 X上の 2項関係 Sは、次の 3つ の条件を満たすとき、半順序関係である。
D ( Vx eX) [xSx] (反射律）
2) (Vx, y≡X) [xSy, ySx→x=y] (反対称律）
3) (Vx, y, z≡X) [ [xSy→ySz]→xSz] (推移律）
[0038] 半順序関係をもつ集合を半順序集合 (partially ordered set)と呼び、頭文字を取つ て、しばしばポセット（poset)ともいう。集合の 2つの要素 x、 y力 SxSy力、 ySxのいずれ かであるとき、比較可能であるという。どの 2つの要素も比較可能な半順序集合を全 川頁序集合（totally ordered set)という。
[0039] 電子取引の関係は、売り手と買い手の関係が非対称であり、対称律を満たさず、反 対称律を満たすため、半順序関係となる。一方、電子商品であるという関係は、売り 手にとっての電子商品は買い手にとっての電子商品でもあるから、対称であり、同値 関係となる。
[0040] 同値関係について強弱を定義することができる。 1つの集合 Xにおける 2つの同値 関係 R、 Sにつ!/、て、 xRy→xSyであるとき、 Rは Sより強!ヽ、 Sは Rより ¾ ヽと!ヽぅ。また 、 Rによる類別は Sによる類別より細力 、、 Sによる類別は Rによる類別より粗いという。 最も強い同値関係は、「同じものである」という同値関係であり、最も弱い同値関係は 、 Xの任意の 2つの要素が同値であるとする同値関係である。
[0041] [5]商空間 (等化空間）
Xを位相空間とする。 fを全射かつ連続な写像であって、各点 xEXを、 Xを含む部 分集合である同値類 χΖ〜ΕΧΖ〜に写像する商写像 (quotient map) (しばしば等 ィ匕写像（identification map)とも呼ばれる）であるとする。
f : X→XZ〜
ここで、既に説明したように、「写像 f : X→Yが全射である」とは、 (VyEY) (ョ xex) [f(x)=y]
を意味する。
[0042] Xの部分集合 XG Xに対して、
X°が開である f_1(X°) | ye Aが Xにおいて開である（これは fが連続であることを 意味する）
が成り立つような全射写像 fを考えた場合、 XZ〜を商写像 (または等化写像) fによる 商空間（または等化空間）と呼ぶ。商空間が等化空間とも呼ばれる理由がある。それ は、既に述べたように、商空間は、各要素である同値類 xZ〜EXZ〜を、 xZ〜に 含まれる点 xexと同一視することにより得られるカゝらである。
[0043] [6]接着空間
さて、位相空間 Xから始めて、これに別の位相空間 Υを接着する。図 1は、 2つの互 いに素である位相空間 X、 Υから接着空間が生成される様子を説明する図である。 画
Yf=YufX = YuX/〜
は、接着写像（attaching map) fによって Yを Xに接着（attach)することにより（または、 連続写像 fにより、各点 yEY
0 I Y CYをその像 f(y) EXと同一視することにより）得 0
られる接着空間（attaching space)である。
[数 5]
U
は、直和 (別名、「排他的論理和」）を表し、しばしば記号 +が代わりに使われる。
[0044] 接着写像 fは、 f:Y→Xである連続写像である。ただし Y CYである。このように、接
0 0
着空間
[数 6]
Yf=Yux/〜 は商空間の一例であり、
[数 7]
YuX/~=YufX=YuX/(x〜f(y) I VyeY0) である。この場合における等化写像（identification map) gは、
[数 8]
Figure imgf000015_0001
である。
[0045] [7]制限と包含
任意の関数 g :Y→Zに対して、 gの Χ(Χ Υ)への制限 (restriction)とは、 [数 9] g | X = g o i ： x→z
である。ここで
i:X→Yは、包含（inclusion)である。すなわち
VxEX, i (x) =x
である。
[0046] [8]連続写像のエクステンションとレトラクシヨン
位相空間 X、 Yと、部分空間 ACXに対して、 f | A:A→Yを満たす連続写像 f :X→
Yを Aから Xへの写像 f | Aの連続エクステンション（または単にエクステンション）とい う。エクステンションは部分関数である。
[0047] 制限 (restriction) rは、 r:X→ Aを満たす X上の恒等写像 1 ： A→ Aの連続エタステ
A
ンシヨンである。したがって、 r I A= l である。
A
[0048] ACXに対して、
[数 10]
i o r 〜 lx
を満たすレトラクシヨン（retraction)r:X→Aがあるならば、 Aを Xの変形レトラタト（defo rmation retract)と呼び、
[数 11]
X ^- ^ A
で表す。 もし、 Aがただ一つの点 A= {a} CXであるならば、 Aはレトラタト可能 (retractable)とい い、
[数 12]
X
Figure imgf000016_0001
氺 で表す。
[0049] [9]ホモトビー
ホモトビーはエクステンションの一例である。 X、 Yを位相空間、 f, g:X→Yを連続写 像、 1=[0, 1]とする。ホモトビーは、次のように設計される。
H:XXI→Y
ただし、 tEIに対して、
t = 0のとき、 H = f
t=lのとき、 H = g
が成り立つ。このとき、 fは gにホモトピックであるという。
[0050] ホモトビーは連続写像のエクステンションであり、
H I XX{0}=fi
0
H I XX{l}=gi
ここで
i =XX{0}→X
o
i =XX{1}→X
[0051] 位相空間 Xと Yは、ホモトピー同値 (homotopically equivalent)
[数 13]
X ^ Y
である、すなわち次の条件が満たされて ヽれば同じホモトビー型である。
[0052] 2つの関数 f、 hは、 f :X→Yおよび h:Y→Xであり、
[数 14]
h ° f ^ lx ana i ° h ^ 1Y
である。ここで 1 および 1 は恒等写像、すなわち 1 :Χ→Χ、 1 ： Υ→Υである。 [0053] ホモトビー同値も同値関係の一例であるが、ホモトビー同値はトポロジー同値よりも 広い概念である。ホモトビー同値は、変化の後、位相幾何学的にはもはや同値では なくなる情報の変化を同定することができる。情報はいろいろな操作や処理により変 化するが、その操作および処理はホモトビーによって指定され、情報の変化はホモト ピー同値によって検証される。事実、不変性 (invariance)という抽象の観点からは、ホ モトピー同値は集合論的同値よりも抽象性が高い。なぜなら、与えられた集合を要素 の追加や削除によって変化させるとき、追加や削除の操作手順と追加もしくは削除さ れた要素を保存することにより、集合をホモトビー同値にすることができるからである。
[0054] [10]セル構造空間（セル空間）
セル (cell)は任意の次元 (たとえば n次元、ただし nは自然数)の閉球（閉の nセルと 呼ぶ）とトポロジー同値 (すなわち同相）である位相空間 Xである。
[0055] 閉の nセル（closed n- cell)を
[数 15]
と表記する。
[0056] 開の nセノレ (open n- cell)を
[数 16]
Int Sn = B "
と表記する（しばしば e11とも書かれる）。
[0057] 閉の nセノレ
[数 17] β ' Ά= {xeR11 ， llxll< l }
【ま、 n次兀閉球体 (closed n— dimensional ball)である。ここで
[数 18] は n次元の実数である。
[0058] 開の nセノレ
[数 19]
Int βη= B f n = {xeRn , llxllく 1}
は、 η次元開球体（open n-dimensional ball)であり、 n次元閉球体
[数 20]
の内部である。
[数 21] 一 B n = s"";
は、閉の nセルの境界であり、これは（n— 1)次元球面（sphere)Sn_1である [0059] 位相空間 Xに対して、特性写像（characteristic map)
[数 22]
r
は、連続関数
[数 23]
T: → X
であり、次を満たす。
[数 24]
Γ:έη-→^(^η), and
T(cWn) = Τ(Β( Ά) - T(Sn)
[0060] [数 25] en = Τ(&λ) は、開の nセノレであり、
[数 26]
は、閉の nセノレである。
[0061] 位相空間 から、整数集合 Zによってインデックスが与えられた、 Xの部分空間であ るセル Xpの有限または無限の系列 {Xp I XPcX) pez}を構成することができる。こ れは、フィルトレーシヨン (filtration)と呼ばれ、次の条件を満たす。 XPは Xの被覆（cov ering)、すなわち X= U XPであり、かつ、 XPは Xの部分空間、
Figure imgf000019_0001
2 … XP_1 ΧΡ … X (これはスケルトン（skeleton)と呼ばれる）である。最大 p次 元のスケルトンは p—スケルトンと呼ばれる。
[0062] C= {X I XPcx, p EZ}を位相空間 Xのセル分解（cell decomposition)、あるいは 、位相空間 Xの、閉セルである部分空間 XPへの分割（partition)という。（X, C)は CW 複体（CW-complex)と呼ばれる。
[0063] セル接着写像を保存しながらセル分解を行うとき、セル空間を再利用可能な資源 に変えることができる。そのような保存され、共有された情報をセルデータベース (cell ular database)と名付け、セルデータベースを管理するシステムをセルデータベース 管理ンスアム (cellular database management systemま 7こは cellular DBMS)と名付け る。
[0064] より正確には、 J. H. C. Whitehead, "Algebraic Homotopy Theory", Proceedings of International Congress of Mathematics, II, Harvard University Press, pp. 354—357, 1 950によれば、位相空間 Xが与えられたとき、
Figure imgf000019_0002
·· XP_1 XP … Χをもったフィルトレーシヨン XPを以下の条件を満たす位相空間として帰納的 に構成することができる。
(1) X CXは、その要素が Xの 0次元セルである部分空間であり、かつ
(2) XPは XP_ 1から次のようにして作られる。すなわち、 XPは、接着写像と呼ばれる全 射かつ連続な写像
[数 27]
Figure imgf000020_0001
によって、 XP_ 1に p次元閉球体の直和（disjoint union)
[数 28]
を接着することによって作られる。
[0065] 言 、換えれば、 Xpは、直和
[数 29]
Figure imgf000020_0002
を求め、
[数 30]
Figure imgf000020_0003
における各点 X、すなわち
[数 31]
Figure imgf000020_0004
を、連続写像
[数 32]
Fi = F I dS^ ： ?¾p→ Χρ
(ただし、各インデックス iに対して X〜f (X)である）
によって、その像
[数 33]
と同一視 (identify)すること〖こよって、 XP_1から構成される。
[0066] このように、 XPは商空間（quotient space)あるいは等化空間（identification space)で あり、 [数 34]
Xp =XP u (ut ¾p)| (x〜F x) I VXG^¾P)
=XP uF (u
と書くことができ、これは、接着空間の一例である。写像 ^はセル
[数 35]
の接着写像の一例である。
[0067] フィルトレーシヨン空間（filtration space)は、フィルトレーシヨンとホモトビー同値な（h omotopically equivalent)空間である。
Figure imgf000021_0001
〜 XP_ ェ ^… Χを合わせて CW空間（CW-space)と呼ぶ。セル複体としては、先に説 明したように、これは CW複体（CW-complex)と呼ばれる。
[0068] このようにして、写像
[数 36]
Ψ
を等ィ匕写像 (identification map)
[数 37]
Figure imgf000021_0002
の一例として得る。
[0069] 各 nセル
[数 38]
¾p = Ti!B^ G Xp
に対する特'性写像（characteristic map)
[数 39]
T
は、 [数 40]
, = r \ ： → xp
と書ける。
[0070] ΧΡ_1を ΧΡの閉の部分空間として埋め込むことは
[数 41]
Τ I χρ = χρ_ 1 → χρ
と書ける。
[0071] CW空間が微分同相（diffeomorphic)であるなら、これは多様体 (manifold)空間と等 価である。
[0072] [11]表現設計
セル空間レベルでセルの次元が設計された後、表現レベルにお!、てセルの表現 (p resentation)が設計される。表現設計では、オブジェクトの属性のデータ型や桁数な どの表現形式が詳細化される。オブジェクトの属性の表現形式に不整合がある場合 、表現形式を受容表現 (Admissible Representation)に合わせる処理が行われる。ォ ブジエタトの属性の表現形式の不整合には、たとえば、データ型または桁数の違いが あり、データ型変換や桁数変換により、その違いを解消することができる。
[0073] [12]ビュー設計
表現レベルでセルの属性の表現形式が詳細化された後、ビュー (view)、すなわち ユーザが見ることのできる範囲が決められる。ユーザは、オブジェクトの集合のうち、 関心のある部分だけを適当な形式で見たいという要求がある。また、セキュリティ上の 理由などによりユーザが参照することのできる範囲を制限しなければならない。その ため、ビュー設計では、ユーザ向けに参照可能なオブジェ外の部分集合や、閲覧可 能なオブジェクトの属性を制限したビューが決められる。
[0074] [13]インクリメンタリモジュラな抽象階層
これまで述べてきたホモトビー、集合、位相空間、接着空間、セル空間、表現、ビュ 一の各抽象レベルは、インクリメンタリモジュラな抽象階層（incrementally modular abs traction hierarchy)を形成— "る。 1.ホモトピーレベル
2.集合論レベル
3.位相空間レベル
4.接着空間レベル
5.セル空間レベル
6.表現レべノレ
7. ビューレべノレ
[0075] これらの階層は、モジュールィ匕されており、各階層においてインクリメンタルに情報 を操作して 、くことが可能であり、サイバーワールドの不変量 (invariant)を示す同値 関係を階層的に継承する上できわめて有用である。
[0076] まず、複数のオブジェクト集合の特定の要素について同値にする対象が選ばれる。
次に、オブジェ外集合に位相が規定され、位相空間において同値関係が規定され ることにより、複数のオブジェ外集合は、同値類の直和である接着空間として設計さ れる。さらに、セル空間において同値セルとそれ以外のセルにセル分解されることに より、セル空間レベルまで同値関係が継承される。
[0077] さらには、受容表現にもとづいてセルの表現形式を規定することにより表現レベル まで同値関係が継承され、最後にユーザのビューが規定されることによりピューレべ ルまで同値関係が継承される。表現レベルの 1つのインスタンスとして、受容表現を 規定するための受容表現レベルを設けておけば、オブジェクトを表現レベルで同値 にすることができる。
[0078] このようにインクリメンタリモジュラな抽象階層モデルでは、同値関係を抽象階層間 で継承しながら、オブジェクトの満たすべき仕様を各階層において設計するため、情 報の追加、削除、修正をインクリメンタルに行いながら、抽象階層間を行き来してォブ ジェタトの仕様を詳細化できる。また、こうして設計されたオブジェクトは再利用可能な 形で部品化することができる。
[0079] 集合 Xの部分集合力 なる集合 Sにおいて、 Sに属するすべての集合の和集合が X に等しいとき、 Sを集合 Xの被覆 (covering)という。 n個の情報システムの統合を行うと き、「経営上の業務統合決定」は、インクリメンタリモジュラな抽象階層の上で、 n個の 集合の被覆を作ることの決定がなされたことに相当する。ここで、業務は別々の機関 のものであってもかまわない。 n個の集合は一般には重なりがある。たとえば、複数の 業務に同じ社員が参加することなどがあるからである。この n個の集合の被覆が、イン クリメンタリモジュラな抽象階層間で継承されることにより、業務統合が実装される。言 い換えれば、ホモトビーレベル、位相空間レベル、接着空間レベル、セル空間レベル 、表現レベル、およびビューレベルのそれぞれで業務の被覆が生成されることが、業 務統合になる。いったん被覆が生成されると、 n個の情報システムの間の統合および 操作は、インクリメンタリモジュラな抽象階層の上ですベて被覆を通して行われる。そ の結果、 n個の情報システムの間の統合および操作は、いずれも線形になる。このよ うに、インクリメンタリモジュラな抽象階層によれば、 n個の情報システムの間で被覆と いう線形インタフェイスを構成して線形インターオペラピリティを実現することができる
[0080] また、インクリメンタリモジュラな抽象階層モデルにおける位相空間は、ノ、ウスドルフ 空間（Hausdorff space)すなわち T位相空間に限られない。 T位相空間では、分離
2 2
公理により、異なる 2点が開集合で分離できるが、異なる 2点を開集合で分離すること のできない T位相空間や T位相空間であっても、同様に接着空間が設計できること
0 1
に留意する。したがって、抽象階層モデルは、非常に汎用性が高いものである。
[0081] 接着空間は、主要な企業や公的機関で用いられている有力な商用の情報システム に共通した特性を接着空間と!/、う形で異なる情報システム間で同値になるように抽象 化し、モデル構築する。このように、接着空間は、異種情報システムを線形統合する ことのできる斬新な情報モデルであり、統合作業量の組み合わせ爆発を避けることに 大いに貢献する。接着空間レベルにおける線形統合後の線形インタフェイス生成の 自動化のために、上記のインクリメンタリモジュラな抽象階層が用いられる。この抽象 階層によれば、同値関係が下位の階層まで継承されるため、既存の情報システムに 対するインタフェイスを与えて、統合システム規模のタスクを実行するための線形イン ターオペラピリティを実現することができる。
[0082] 比較のために、リレーショナルデータベースシステムを例に挙げて説明する。リレー ショナルデータベースシステムにおいて、リレーションはタツプルの集合である。リレー シヨンに新たなタツプルが挿入されたり、既にあるタツプルが削除されたり、タツプルの 属性値が修正されることにより、リレーションは時間とともに変化していく。たとえば、リ レーシヨンとして「社員 (社員番号，氏名，所属，入社年度)」を考える。新しい社員が 入社した場合、リレーション「社員」にその社員を表すタツプルを挿入しなければなら ない。一方、ある社員が退職すると、リレーション「社員」にその社員を表しているタツ プルを削除しなければならない。また、配置換えにより、ある社員の配属先が変わつ た場合、その社員のタツプルにぉ 、て属性「所属」の値を修正しなければならな!/、。
[0083] このように、リレーショナルデータバースでは、タツプルの挿入、削除、修正により、リ レーシヨンが時間とともに変化していく。しかしながら、リレーションには、社員の社員 番号、氏名、所属、入社年度のデータを表しているという固有の性質があり、これは 時間に対して不変である。リレーションにはこのように時間に対して不変な構造があり 、これをリレーションスキーマと呼んでいる。
[0084] リレーショナルデータベースモデルは、集合論にもとづくものであるから、位相空間 のレベルで同値関係を定義することができない。したがって、複数の異なるデータべ ースを統合しょうとすると、 IDのつけなおしなど、データベースの再設計を行う必要が あり、工数爆発の問題が起こる。それに対して、インクリメンタリモジュラな抽象階層モ デルでは、上位概念で規定された同値関係を表現レベルまで落とし込むことができ るため、複数の異なる情報システムの統合が線形操作で可能となる。すなわち情報 システムの各要素のインタフェイスは、接着空間に一回変換するだけでとることができ 、 n要素で n回の変換でインターオペラピリティが保証され、インタフェイスの数は線形 である。
[0085] このように、本発明の抽象階層モデルに対して、従来のリレーショナルモデルは、同 値関係をモデルィ匕していないため、情報の統一的な扱いができない。せいぜい、テ 一ブル間の関係を示す別テーブルを、ノ ツチを当てる要領で設けてインタフェイスを とろうとしている力 これではインタフェイスの数が指数関数的に増える。一方、 ER(E ntity Relation)モデルを基本とする SAP、 UML(Unified Modeling Language)なども、 これらはすべて直観的なグラフ理論モデルであり、そのモデル自身が同値関係を扱 うことができないため、同様の問題が起こる。これが社会基盤情報システムの現状で あり、システムが明確なインターオペラピリティをもたな 、ことが大きな問題となって!/ヽ る。
[0086] [14]応用例
[14. l]Web情報モデリング
通常、 Web情報マネージメントシステムのやるべき仕事は、 Webグラフィックスを用 いて情報を可視化することを通して、人間の認識との間で非常に近い相互作用をも ちながら、 Web上の情報を管理することである。 Webグラフィックスの仕事は、人間の 理解のためにグラフィックススクリーンに 、ろ 、ろなイメージを投影することである。人 間は、ディスプレイ空間に表示されたイメージを人間の認識空間における認識対象 物にリンクすることによって、表示されたイメージを理解している。しばしば、幾何学的 に正確な表示であっても、サイバーワールドでは通常は本質的な情報ではない、優 先度の低い幾何学的形状によって、人間の認識を誤りに導くことがある。 Web情報マ ネージメントに対して Webグラフィックスは、サイバーワールドの変化に合った速度で 、人間が即座に認識できるようにスクリーン上に重要なメッセージを伝えることができ なければならない。以下、簡単な例を挙げて説明する。
[0087] [14. 2]エレクトロニックファイナンスの Web情報モデリング
エレクトロニックファイナンスにおいて、顧客 Xが、 Webサーフィンしているときに、金 融取引会社 Yのホームページの Webページに投稿されている収益の期待できるファ ンド Ύを見つけたとする。この時点では、顧客 Xは Webで「ウィンドウショッピング」をし
0
ている段階であるから、顧客 Xと取引会社 Yはファンドをまだ共有していない。したが つて、 Xと Yは互いに素であり、共通要素を持たない。すなわち、
[数 42]
YUX
と表記することができる。一般化のために、 Xと Yを位相空間とする。ファンド Ύは金
0 融取引会社 Yの属性の一部であるから、 Y CYが成り立つ。図 2は、 Web上のエレク
0
トロニックファイナンスのプロセスを Webグラフィックスにおいて図示したものである。 次に、ファンドが取引のために特定された後、顧客 Xは取引会社 Yとどのようにして関 係づけられるかを述べる。ここで提案する Web情報モデルは、顧客 Xと取引会社 Yの 関係を接着写像 fによって正確に表現し、また、「ファンド Ύが取引のために特定され
0
て 、る」と 、う状況を 2つの互いに素である位相空間 X(顧客）と位相空間 Y (金融取 引会社)の接着空間として表現する。この接着空間は、顧客 Xから始めて、金融取引 会社 Yを顧客 Xに接着することにより得られる。ここで、 Yの Xへの接着は、連続写像 f を介して、各点 y£Y I γ Υをその像 f (y) exと同一視することによって行われ、
0 0
その結果、 x〜f (y) I VyEYである。このように、〜で表記される同値は、 Web情報
0
の接着空間モデルとして接着空間を作成するために、 Web情報モデリングにお 、て 中心的な役割を果たす。
[0088] 上記の接着空間モデルは、エレクトロニックマ-ュファクチャリングにおいてもまった く本質的に等しく適用することができる。エレクトロニックマ-ュファタチャリングプロセ スを管理し、表示するために正確に同一の技術が要求される。エレクトロニックマ-ュ ファタチャリングが巿場の需要に効果的に即応するためには、 V、かにして 、ろ 、ろな サイズのコンポーネントを統一したデザインで組み立てるかを指定しなければならな い。先に提示したエレクトロニックファイナンスは、顧客と取引会社をエレクトロニックマ -ュファタチャリングのコンポーネントとして組み立てることであると考えることにより、 エレクトロニックファイナンスのための Web情報マネージメントシステムと Webグラフィ ックスは、実際にエレクトロニックマ-ュファクチャリングに適用可能となる。もし、異な るアプリケーションに異なる技術を使うとなると、急成長しているサイバーワールドは、 タイムリーに Web情報マネージメントシステムで管理することも、 Webグラフィックスで 表示することもできなくなる。
[0089] [14. 3]エレクトロニックマ-ュファクチャリングの Web情報モデリング
接着空間モデルによるエレクトロニックマ-ュファクチャリングの Web情報モデリング はまったく簡単である。基本的には、エレクトロニックマ-ュファクチャリングと呼ばれる Web上のマ-ュファタチャリングは、エレクトロニックマ-ュファクチャリングの工程に 関する次の情報力 なる Web情報としてモデルィ匕される。
1)製品仕様
2)組み立て仕様
3) Web上での部品購入 4) Web上の組み立てサイトでの購入
[0090] 各ステップは、必要に応じてより細力 、サブステップに分解される。たとえば、ステツ プ 1は次のサブステップに分解できる。
1. 1)電子市場での製品のマーケット調査
1. 2)マーケット調査力 導き出される製品の要求
1. 3)要求を満たすための製品の仕様
[0091] エレクトロニックマ-ュファクチャリングのための Web技術全体の中で核となる部分 は、 Web情報モデリングとしての Web上での製品と組み立てのモデリングである。図 3は、座席と支持部という 2つのコンポーネントをもつ椅子の単純な組み立て例を用い て、最も初歩的な組み立てのモデリングを明確に図示したものである。発展したマ- ュファクチャリングとしてのエレクトロニックマニュファタチャリングにおいて、製品のコ ンポーネントは、モジュール化されており、より品質の高いコンポーネントを買うため、 最も有効なアップグレードを行うため、あるいは修理するために置き換え可能に構成 されている。
[0092] エレクトロニックファイナンスとエレクトロニックマ-ュファクチャリングが接着空間と同 値にもとづいて同一の情報モデリングを共有することは明らかである。
[0093] [15]実施例
図 4は、実施の形態に係るソフトウェア開発支援装置 100の構成を示す。オブジェ タト集合記憶部 190は、ソフトウェア開発に利用されるオブジェクトの集まりを保持す る。ソフトウェア開発に利用されるオブジェクトすなわちソフトウェア部品は、データ構 造体やプログラムモジュールである。ソフトウェア開発支援装置 100は、オブジェクト 集合記憶部 190に格納されたオブジェクトの集まりを参照する。ソフトウェア開発支援 装置 100は、オブジェクト集合記憶部 190を介さずに、ウェブ上の情報システムから オブジェクト集合を取得して参照してもよい。以下、実施の形態では、説明の便宜上 、 2つのオブジェクト集合の間に所定の対応関係またはインタフェイスを定義する場 合を説明するが、これはより一般的に複数のオブジェクト集合を参照してそれらの間 にインタフェイスを定義する場合の一例に過ぎな 、。
[0094] ソフトウェア開発支援装置 100は、ホモトビーレベル処理ブロック 110、集合レベル 処理ブロック 120、位相空間レベル処理ブロック 130、接着空間レベル処理ブロック 1 40、セル空間レベル処理ブロック 150、表現レベル処理ブロック 160、およびビュー レベル処理ブロック 170を含み、それぞれ既に述べたインクリメンタリモジュラな抽象 階層モデルにおける各階層レベルの処理を行う。
[0095] 集合レベル処理ブロック 120は、オブジェクト集合記憶部 190に格納されたォブジ ェ外の集まりに集合演算を適宜施して、設計対象となる 2つのオブジェ外集合を特 定する。位相空間レベル処理ブロック 130は、集合レベル処理ブロック 120が特定し た 2つのオブジェクト集合に対して位相を規定することで、 2つのオブジェクト集合は それぞ; |1 ^立相空間 X、 Yとして設計する。この時点で 2つの位相空間 X、 Yは互いに 素であり、これらの位相空間 X、 Yの直和あるいは排他的論理和である
[数 43]
YUX
が確定する。
[0096] 接着空間レベル処理ブロック 140は、図 5にその詳細な構成を示すように、同値関 係設定部 44、同値関係保持部 52、対応要素抽出部 20、接着写像取得部 22、等化 写像取得部 24、手順取得部 26、および手順記録部 28を含む。
[0097] 同値関係設定部 44は、 2つのオブジェクト集合に適用したい同値関係の入力をュ 一ザ力も受け付ける他、ユーザの入力をもとにして自動的に同値関係を生成する。ュ 一ザが同値関係を設定しやすいように、同値関係保持部 52は同値関係の候補があ らかじめ格納されている。また、ユーザがオブジェクト集合の要素を指定して同値関 係を記述することのできるインタフェイスを設けてもよい。
[0098] 同値関係設定部 44により設定された同値関係 (以下、目的同値関係ともいう）は、 対応要素抽出部 20へ伝えられる。対応要素抽出部 20は、 2つのオブジェクト集合に おいて対応関係を定義すべき構成要素 (以下、「対象要素」ともいう)を、目的同値関 係をもとに抽出する。その際、ユーザが 1つのオブジェクト集合において対象要素の 一方を指定し、対応要素抽出部 20が目的同値関係をもとに他方のオブジェクト集合 から対応する対象要素を抽出するようにしてもょ ヽ。
[0099] 対応要素抽出部 20により対応しあうことが判明した対象要素は、ひとつの部分位相 空間、すなわち同値類を形成し、接着空間モデルの理論的保証により、同値類の排 他的論理和として接着空間が形成される。同値類は同値関係で規定される不変量を もとに分類されるため、オブジェクト集合を客観的に分類することができ、分類の結果 にはシステム設計者による個人差が含まれない。また、一方の対象要素を決めると、 他方の対象要素が決まるため、前述のごとぐ対応関係またはインタフェイスの数が 線形になり、インターオペラピリティが保証されることになる。
[0100] 目的同値関係が決まると、対象要素間がどのような意味において対応するか、その 関係も一意に決まる。そのため、接着写像取得部 22は対象要素間の対応を示す接 着写像 fを特定することができる。接着写像 fが決まると、接着空間も、
[数 44]
Y ufx = Y u x /〜 と定まる。接着空間は、もとは共通部分をもたない位相空間 Xと Yの間に、接着写像 f を媒介として対応関係を持たせた位相空間である。
[0101] 等化写像取得部 24は、位相空間 Xと Yの単なる排他的論理和の空間から、接着写 像 fによって定まる接着空間への写像である等化写像 gを取得する。等化写像 gは、 現実には、その定義力 位相空間 X、 Yおよび接着写像 fによって記述することができ る。
[0102] 手順取得部 26は、同値関係設定部 44から目的同値関係、対応要素抽出部 20か ら対象要素、接着写像取得部 22から接着写像 f、等化写像取得部 24から等化写像 g の入力を受け、ユーザにより指定された対象要素および目的同値関係（以下、これら を「注目手順」ともいう）をホモトビーとして、一連の処理の結果で特定される、 •位相空間 X、 Y
•目的同値関係
'接着写像 f
'等化写像 g
と関連づけて手順記録部 28へ記録する。
[0103] セル空間レベル処理ブロック 150は、図 6にその詳細な構成を示すように、セル接 合部 62、セル次元調整部 64、および対応テーブル保持部 66を含む。セル空間レべ ル処理ブロック 150は、接着空間レベル処理ブロック 140において目的同値関係を もとに接着空間として設計された複数のオブジェクト集合の仕様を継承して、セル空 間レベルでオブジェクト集合の仕様を詳細化する。セル構造空間モデルは、接着空 間モデルに次元を導入したものであり、オブジェクトの属性の IDや属性の個数に関 する仕様がセル空間レベルで詳細化されることになる。
[0104] セル接合部 62は、 2つのオブジェクト集合間で目的同値関係により対応関係にある 2つの対象要素を接合し、各オブジェクト集合に属するオブジェクトの属性をセルで 表現する。セル次元調整部 64は、対応する 2つの対象要素間に属性の次元に関す る不整合がある場合、その不整合を解消するための処理を行う。セルの次元に関す る不整合として、対象要素の属性の IDや個数の違いなどがある。セル次元調整部 6 4は、必要に応じて、 2つの対象要素間で属性の IDや属性の個数の不揃いを調整し 、 2つの対象要素間の属性の対応関係を示すテーブルを対応テーブル保持部 66に 格納する。
[0105] 表現レベル処理ブロック 160は、図 7にその詳細な構成を示すように、表現生成部 72、表現形式調整部 74、および変換テーブル保持部 76を含む。表現レベル処理ブ ロック 160は、セル空間レベル処理ブロック 150においてセル空間レベルで詳細化さ れたオブジェクト集合の仕様を継承して、表現レベルでオブジェクト集合の仕様をさ らに詳細化する。表現レベルでは、セルの具体的な表現形式を決めるため、ォブジ ェ外の属性のデータ型や桁数などに関する仕様が詳細化されることになる。
[0106] 表現生成部 72は、 2つのオブジェクト集合のそれぞれに属するオブジェクトの属性 の表現を生成する。表現形式調整部 74は、目的同値関係により対応関係にある 2つ の対象要素間に表現レベルの不整合がある場合に、その不整合を調整するための 処理を行う。表現レベルの不整合として、対象要素の属性のデータ型や桁数の違い などがある。データ型には、ブール値、符号付き整数、正の整数、実数、倍精度実数 、文字型などがあり、表現形式調整部 74はこれらのデータ型を変換して対象要素の データ型を揃えてもよい。また、データ型が同じでも文字列の桁数や数値の有効桁 数などの桁数が異なる場合には、表現形式調整部 74は 2つの対象要素間で属性の 桁数を調整して揃えてもよい。その他の不整合の例として、計量や貨幣などの単位の 違いがあり、変換式を用いて、一方の単位系が他方の単位系に変換される。
[0107] 表現形式調整部 74は、位相空間 Yを位相空間 Xに接着する場合、表現レベルに お!、て、位相空間 Xのオブジェクト集合の対象要素と位相空間 Yのオブジェクト集合 の対象要素の属性のデータ型や桁数を比較して、相対的に精度が高い方の属性に 揃えて、データ型や桁数を変換する。 3つ以上のオブジェクト集合の対象要素間で属 性の表現レベルの不整合を調整する場合も同じであり、表現形式調整部 74は、複数 のオブジェクト集合の対応する対象要素の属性表現の内、最も精度の高い属性表現 を選んで、他の精度の低!、対象要素の属性表現をその精度の高 、対象要素の属性 表現に合わせるように調整する。これにより、精度の異なる対象要素の接着後に、デ ータ型変換や桁落ちなどにより元のデータが失われるのを防ぐことができる。
[0108] 表現形式調整部 74は、最大の文字数や桁数をもった受容表現をもった表現フィル タとして作用し、当該表現フィルタを通過した表現は、表現レベルで同値になる。表 現形式調整部 74は、表現の不整合の調整をした場合の変換規則を記述したテープ ルを変換テーブル保持部 76に格納する。
[0109] ビューレベル処理ブロック 170は、ユーザに合わせたビューを設定し、ビューにした 力 てオブジェクト集合をディスプレイなどに表示する。
[0110] ホモトビーレベル処理ブロック 110は、ソフトウェア開発支援装置 100の各処理ブロ ックがオブジェクト集合に対して操作を行った際、その操作によって生じるオブジェク ト集合の変化がホモトビー同値になるように保証する。ホモトビーレベル処理ブロック 110は、手順記録部 28に記録された接着空間生成に係る注目手順、対応テーブル 保持部 66に格納されたセルの次元の不整合の対応関係を示すテーブル、変換テー ブル保持部 76に格納されたセルの表現の変換規則を示すテーブルを利用し、各操 作によってオブジェクト集合にもたらされた変化を逆にたどることにより、オブジェクト 集合を変化前の状態に戻すことができる。
[0111] このようにして、集合レベル処理ブロック 120から始めて、位相空間レベル処理ブロ ック 130、接着空間レベル処理ブロック 140、セル空間レベル処理ブロック 150、表 現レベル処理ブロック 160、およびビューレベル処理ブロック 170へと、同値関係を 継承しつつ、 2つのオブジェクト集合の仕様を段階的に詳細化していくことで、 2つの オブジェクト集合が表現レベルまで同値となって出力される。このようにインクリメンタ リモジュラな抽象階層モデルにもとづくソフトウェア開発支援装置 100は、同値関係 を、集合レベル力 位相空間レベル、接着空間レベル、セル空間レベル、表現レべ ル、およびビューレベルまで保証する一貫性のあるフィルタとして機能し、フィルタを 通過したオブジェクト集合は同値関係が数学的に保証されたインスタンスとなって出 力される。
[0112] 対応づけたい構成要素が複数あれば、それぞれの構成要素について目的同値関 係を設定することによって、同様に接着写像が規定され、最終的に複数のオブジェク ト集合間で対応する要素が接着された結果が出力される。一方のオブジェ外集合が 注目する構成要素を n個もてば、その n個のそれぞれについて、他方のオブジェクト 集合のいずれかの構成要素との対応関係が特定されるため、インタフェイス数は線 形であり、工数爆発の問題が解決する。
[0113] 本実施の形態によれば、同値関係を設定すれば、複数のオブジェクト集合の構成 要素間で対応づけができ、対応していない構成要素はそのまま残しつつ、同値関係 にある構成要素については常に同じ情報をもつことができ、不変量を切り口に分類 や対応づけができるので、データ利用性が向上し、ソフトウェア開発の効率を各段に 高めることができる。
[0114] [16]具体例
以上の構成のソフトウェア開発支援装置 100によるソフトウェア開発支援手順の具 体例を説明する。ソフトウェア開発支援装置 100が各種プログラムモジュールをもと にソフトウェアを開発する際、プログラムモジュール間のインタフェイスを確定し、各プ ログラムモジュールで利用されるデータの仕様を詳細化する。 [16. 1]でデータの設 計手順を述べ、 [16. 2]でプログラムモジュールの設計手順を述べる。
[0115] [16. 1]データ設計
ソフトウェアにお 、て利用される複数のオブジェクト集合の一例として、シューズショ ップ Xのオブジェクト集合 300と、シューズメーカー Yのオブジェクト集合 200を考える 。これらのオブジェクト集合は、集合レベル処理ブロック 120によって設計され、ォブ ジェタト集合記憶部 190に格納されている。これらのオブジェクト集合はデータベース として管理されているものであってもよい。位相空間レベル処理ブロック 130は、シュ ーズショップ Xのオブジェクト集合 300を位相空間 Xとして、シューズメーカー Yのォブ ジェタト集合 200を位相空間 Yとして設計する。この時点で、 2つの位相空間 X、 Yは 互いに素である。
[0116] 接着空間レベル処理ブロック 140は、オブジェクト集合記憶部 190に格納されたシ ユーズショップ Xのオブジェクト集合 300を位相空間 Xとして、シューズメーカー Yのォ ブジェクト集合 200を位相空間 Yとして参照し、同値関係をもとに 2つの位相空間 X、 Y力も接着空間を生成する。図 8に、接着空間レベル処理ブロック 140により 2つの位 相空間が接着される様子を示す。
[0117] V、ま、シューズメーカー Yの製造する特定の運動靴 Yをシューズショップ Xが仕入
0
れて、販売しているとする。このとき、ソフトウェアの開発者は、シューズショップ Xのォ ブジェクト集合、シューズメーカー Yのオブジェクト集合との間でこの運動靴 Yをプロ
0 グラム上では同一のオブジェクトとして扱いたい。同値関係設定部 44は、シューズメ 一力一 Yとシューズショップ Xの位相空間の間で、注目すべき対象要素である運動靴 Yを同値関係にあるものとして設定する。
0
[0118] 対応要素抽出部 20は、シューズメーカー Yの運動靴 Y (符号 202)に対応するシュ
0
ーズショップ Xの運動靴 f (Y ) (符号 302)を抽出する。接着写像取得部 22は、この
0
対応関係をもとに、接着写像 f :Y→X Yを取得する。
0 I Y
0
[0119] 等化写像取得部 24は、接着写像取得部 22が取得した接着写像 fによって、シユー ズショップ Xとシューズメーカー Yの 2つの位相空間の排他的論理和を接着空間 [数 45]
Yf =YufX
に写像する等化写像 gを取得する。すなわち、等化写像取得部 24は、等化写像 [数 46] g:YuX→YUfX
を取得する。ここで、 [数 47]
Yf =YufX=YuX/~=YuX/(x〜f(y) I VyeY0)
であり、同図に示すように、運動靴 f (Y ) (符号 402)において 2つの位相空間 X、 Y
0
が接着する。
[0120] 図 9は、シューズメーカー Yの位相空間における運動靴 202のセル構造を説明する 図である。運動靴 202は、セルの属性として、靴のブランド名 210、会社名 212、種 類 214、サイズ 216、色 218、素材 220、希望小売価格 222、製造原価 224、および 原産国 226を含む。
[0121] 図 10は、シューズショップ Xの位相空間における運動靴 302のセル構造を説明す る図である。運動靴 302は、セルの属性として、靴のブランド名 310、メーカー名 312 、種類 314、サイズ 316、色 318、素材 320、売価 322、および販売店 324を含む。
[0122] セル空間レベル処理ブロック 150のセル接合部 62は、図 9に示すシューズメーカー Yの位相空間における運動靴 202と、図 10に示すシューズショップ Xの位相空間に おける運動靴 302をセルレベルで接合するため、共通する属性を互いに対応づける 。靴のブランド名 210、 310、種類 214、 314、サイズ 216、 316、色 218、 318、素材 220、 320は属性名が一致するため、共通する属性として対応づけられる。
[0123] シューズメーカー Yの運動靴 202の会社名 212と、シューズショップ Xの運動靴 302 のメーカー名 312は、属性名は異なるが同一の要素である。そこで、セル空間レベル 処理ブロック 150のセル次元調整部 64は、シューズメーカー Y側の属性名をシユー ズショップ X側の属性名に対応づけ、接合セルにおける属性名を「メーカー名」に統 一することで不整合を調整し、シューズメーカー Y側の「会社名」をシューズショップ X 側の「メーカー名」に対応づける関係を記述したテーブルを対応テーブル保持部 66 に保持する。
[0124] シューズメーカー Yの運動靴 202とシューズショップ Xの運動靴 302をセルレベルで 接合する際、一方の位相空間に属性が存在し、他方の位相空間にはそれに対応す る属性が存在しないことがある。たとえば、シューズメーカー Yの運動靴 202には、原 産国 226という属性がある力 シューズショップ Xの運動靴 302には、それに対応する ものがない。逆に、シューズショップ Xの運動靴 302には、販売店 324という属性があ る力 シューズメーカー Yの運動靴 202には、それに対応するものがない。このように 、 2つの対象要素間で属性の対応付けをする際、第 1の位相空間に属性 aが存在し、 第 2の位相空間にはそれに対応する属性が存在しない場合、第 1の位相空間の属性 aには対応づけられる属性がないとものして処理する力、もしくは第 2の位相空間にお いて空の属性 bを追加して第 1の位相空間の属性 aと対応づける処理を行う。たとえ ば、セル次元調整部 64は、シューズメーカー Yの運動靴 202の原産国 226について は対応づけられる属性がないとして処理し、一方、シューズショップ Xの運動靴 302 の販売店 324につ 、ては、空の属性をシューズメーカー Yの運動靴 202に追カロし、 シューズショップ Xの運動靴 302の販売店 324と対応づける処理を行 、、属性の個数 に関する不整合を調整する。
[0125] 属性の個数の調整の他の例として、一方の位相空間に「名前」という 1つの属性が あり、他方の位相空間には、「姓」と「名」という 2つの属性がある場合、実質的には両 者は同一の属性であるから、セル次元調整部 64は、「名前」という 1つの属性と、「姓」 と「名」と 、う 2つの属性を対応づけることで、属性の個数の不整合を調整することが できる。
[0126] 図 11 (a)〜（c)は表現レベルでの不整合の調整を説明する図である。シューズメー カー Y側の会社名 212は、図 11 (a)に示すように、 M桁の文字列で表現されている。 一方、シューズショップ X側のメーカー名 312は、図 11 (b)に示すように、 L桁の文字 列で表現されている。ここで、 L< Mである。表現レベル処理ブロック 70の表現形式 調整部 74は、桁数の大きい M桁に合わせて、図 11 (c)に示すように、接合セルの属 性であるメーカー名 412の表現形式を決めてもよい。
[0127] 対象要素の属性の表現形式において桁数の違いがあるときに、桁数の大きい方に 合わせて表現することは、「受容表現レベル」の一例である。表現形式調整部 74は、 所定の受容表現レベルをフィルタとして用いることにより、対象要素の属性の表現形 式の不整合を調整する。
[0128] 図 12 (a)〜（d)も表現レベルでの不整合の調整を説明する図である。シューズメー カー Y側のサイズ 216は、図 12 (a)に示すように、 inchを単位とした実数値で表現さ れている。一方、シューズショップ X側のサイズ 316は、図 12 (b)に示すように、 cmを 単位とした実数値で表現されて 、る。
[0129] ソフトウェアの設計仕様として、 cmの単位を採用する場合、表現レベル処理ブロッ ク 160の表現形式調整部 74は、図 12 (c)に示すように、接合セルの属性であるサイ ズ 416の表現形式は cmを単位とすることにし、シューズショップ X側のサイズ 316の 属性値を用いる。このとき、表現形式調整部 74は、図 12 (d)に示す変換式 516を変 換テーブル保持部 76に格納しておき、属性値の互換性を保つ。このようにいずれか の単位系に合わせることも受容表現レベルの一例である。
[0130] 図 13 (a)〜（d)も表現レベルでの不整合の調整を説明する図である。シューズメー カー Y側の色 218は、図 13 (a)に示すように整数値で表現されている。一方、シユー ズショップ X側の色 318は、図 13 (b)に示すように文字列で表現されている。これは、 シューズメーカー Yでは靴の色を細力べ識別するための番号体系を利用するのに対 して、シューズショップ Xでは靴の色を顧客が理解しやすい「紺」「紫」などの名称で記 述する力らである。この違いは、シューズメーカー Y、シューズショップ Xのそれぞれの システムにおける設計者の設計意図や顧客のニーズにより生じたものである。
[0131] ソフトウェアの設計仕様として、色の表現形式を文字列とする場合、表現レベル処 理ブロック 160の表現形式調整部 74は、図 13 (c)に示すように、接合セルの属性で ある色 418の表現形式を文字列として、シューズショップ X側の色 318の属性値を用 いる。このとき、表現形式調整部 74は、図 13 (d)に示すように、シューズメーカー Υ側 の色を識別する整数値とシューズショップ X側の色を識別する文字列との間の変換 規則を示した変換テーブルを作成して、変換テーブル保持部 76に格納し、属性値 の互換性を保つ。このように文字列の表現形式に変換することも受容表現レベルの 一例である。
[0132] 上記の例では、ソフトウェアの開発者がシューズショップ Xとシューズメーカー Υの 間で同値関係にある運動靴を指定した力 シューズショップ Xと複数のシューズメー カー Υとの間で同値関係を指定してもよい。たとえば、「素材が革である靴」という同値 関係をもとに、シューズショップ Xの位相空間と、複数のシューズメーカー Yl, Υ2, · ··, Υηのそれぞれの位相空間との間で対応する構成要素を抽出し、接着空間を生 成し、オブジェクトのデータ設計を行ってもよい。 [0133] [16. 2]プログラムモジュールの設計
オブジェクト集合の一例として、プログラムを考え、本実施の形態に係るソフトウェア 開発支援装置 100により、複数のプログラムをもとにソフトウェアを開発する手順を説 明する。
[0134] 図 14 (a)、 (b)は 2つのプログラム Xとプログラム Yが統合される様子を説明する図 である。これらのプログラムは、いずれも画像処理を行うものである力 プログラムの開 発者が異なるなどの理由で、プログラム構成が異なっているとする。これらのプロダラ ムは、いずれも画像の符号ィ匕および復号の機能をもっており、たとえば、電子商取引 で売買される商品の画像の符号ィ匕および復号を行うことができる。
[0135] 集合レベル処理ブロック 120は、複数のモジュールからなるプログラム X、 Υを集合 として設計し、位相空間レベル処理ブロック 130は、プログラム X、 Υを位相空間とし て設計する。
[0136] 接着空間レベル処理ブロック 140の同値関係設定部 44は、プログラム X、 Υを構成 するモジュールに対して、「符号化処理機能をもつ」および「復号処理機能をもつ」と いう 2つの同値関係を設定する。対応要素抽出部 20は、同値関係設定部 44により設 定された 2つの同値関係をもとにプログラム X、 Υ間の対応するモジュールを特定し、 接着写像取得部 22は、各同値関係による対応関係を与える接着写像 f 、 f を取得す
1 2 る。
[0137] これにより、プログラム Yの位相空間は、符号ィ匕処理機能をもつモジュール Yと、圧
0 縮処理機能をもつモジュール Yと、それ以外の機能をもつモジュールの直和
[数 48]
Figure imgf000038_0001
に分割され、一方、プログラム Xの位相空間は、符号ィ匕処理機能をもつモジュールで γに対応する f (Y )と、圧縮処理機能をもつモジュールで γに対応する f (Y )と、そ
0 0 1 1 れ以外の機能をもつモジュールの直和
[数 49] に分割される。
[0138] 等化写像取得部 24は、図 14 (a)に示すプログラム X、 Yの 2つの位相空間の直和 を図 14 (b)に示す接着空間
[数 50]
Figure imgf000039_0001
に写像する等化写像 gを取得する。
[0139] 図 15 (a)、 (b)は、接着写像により対応づけられた 2つのモジュール A、 Bの入出力 インタフェイスを説明する図である。モジュール Aの入力に使われて ヽる変数は整数 型の a、 bの 2つであり、出力に使われている変数は実数型の cである。一方、モジュ ール Bの入力に使われている変数は実数型の s、 tの 2つであり、出力に使われている 変数は実数型の uである。接着空間レベル処理ブロック 140において対応づけられ た 2つのモジュール A、 B間で入力変数、出力変数の名前に違いがある力 セル空間 レベル処理ブロック 150のセル次元調整部 64は、 2つのモジュール A、 Bの入力変数 、出力変数の名前を対応が取れるように調整する。また、 2つのモジュール A、 B間で 入力変数、出力変数の個数に違いがあれば、セル次元調整部 64は、 2つのモジュ 一ル八、 Bの入力変数、出力変数の個数を対応が取れるように調整する。
[0140] 表現レベル処理ブロック 160の表現形式調整部 74は、 2つのモジュール A、 Bの入 力変数、出力変数のデータ型に違いがあれば、データ型を調整する。モジュール A の入力変数は整数型であり、モジュール Bの入力変数は実数型であるから、たとえば 、モジュール Aの入力変数を実数型に変換する。また、変数が文字型の場合は、表 現形式調整部 74は、文字列の桁数の調整を行う。
[0141] 図 16〜図 19において、ソフトウェア開発支援装置 100によって、同値関係をもとに モジュールもしくはデータが対応づけられてソフトウェアが開発される手順を説明す る。
[0142] 図 16 (a)、 (b)は、プログラムモジュールが新しいバージョンに更新される様子を説 明する図である。図 16 (a)のように、新バージョンのモジュール A と旧バージョンの
new
モジュール A があるとする。それぞれ別の開発者が設計したものであってもよい。同
old
値関係によって新バージョンのモジュール A が旧バージョンのモジュール A に対 応づけられる。また、それに伴!、、新バージョンのモジュール A の入力変数 s、 tが、 new
旧バージョンのモジュール A の入力変数 a、 bにそれぞれ対応づけられ、新バージョ old
ンのモジュール A の出力変数 uが旧バージョンのモジュール A の出力変数 cに対 new old
応づけられる。
[0143] このように同値関係で新旧バージョンのモジュールを対応づけることにより、ソフトゥ エア開発支援装置 100は、図 16 (b)のように、旧バージョンのモジュール A を新バ old 一ジョンのモジュール A に置き換えて、更新することができる。ソフトウェア開発支 new
援装置 100は、モジュールの置き換えをホモトビー同値になるように行うため、必要に 応じて新バージョンのモジュール A を旧バージョンのモジュール A に戻すことも new old
でき、ソフトウェアのデバッグを効率良く行うことができる。
[0144] 図 17 (a)、 (b)は、 2つのプログラムモジュールが合成される様子を説明する図であ る。図 17 (a)のように、モジユーノレ Aは 2つのサブモジユーノレ A 、 Aをもち、モジユー
1 2
ル Bは 2つのサブモジュール B 、 Bをもつ。同値関係によってモジュール Bのサブモ
1 2
ジュール Bがモジュール Aのサブモジュール Aに対応づけられる。また、それに伴 い、サブモジュール Bの入力変数 sとサブモジュール Aの入力変数 aが対応づけら れる。
[0145] 図 17 (b)のように、同値関係により定まる接着写像によって、モジュール Bのサブモ ジユーノレ Bがモジュール Aのサブモジュール Aと同一視されることにより、 2つのモジ ユール A、 Bが合成され、 1つのプログラムが生成される。このとき、接着写像で対応 づけられたサブモジュール Bとサブモジュール Aの入出力変数のデータ型や桁数 などが調整される。ソフトウェア開発支援装置 100は、モジュールの合成をホモトビー 同値になるように行うため、必要に応じて合成されたプログラム力も元のモジュール A 、 Bを分離して取り出すこともできる。
[0146] このように、ソフトウェア開発支援装置 100は、同値関係をもとにして複数のモジュ ールを合成したり、合成されたプログラム力 モジュールを取り出したりすることができ 、ソフトウェアの部品化を進め、再利用性を高めることができる。
[0147] 図 18 (a)、 (b)は、 2つのプログラムモジュール間でデータが共有される様子を説明 する図である。図 18 (a)のように、 2つの変数 a、 bを入力して変数 cを出力するモジュ ール Aと、 2つの変数 s、 tを入力して変数 uを出力するモジュール Bとがあり、モジユー ル Bの入力変数 sとモジュール Aの入力変数 aが同値関係によって対応づけられ、そ れ以外の変数の間には対応関係がないとする。
[0148] 図 18 (b)のように、同値関係により定まる接着写像によって、モジュール Bの入力変 数 sがモジュール Aの入力変数 aと同一視されることにより、 2つのモジュール A、 B間 で入力変数の 1つが共有される。このように、ソフトウェア開発支援装置 100は、プロ グラムモジュール間で同値類として対応づけられるデータを共有し、データの利用性 を高めることができる。
[0149] 図 19 (a)、 (b)は、 2つのプログラムモジュールが結合される様子を説明する図であ る。図 19 (a)のように、 2つの変数 a、 bを入力して変数 cを出力するモジュール Aと、 2 つの変数 s、 tを入力して変数 uを出力するモジュール Bとがあり、モジュール Bの出力 変数 uとモジュール Aの入力変数 aが同値関係によって対応づけられ、それ以外の変 数の間には対応関係がないとする。
[0150] 図 19 (b)のように、同値関係により定まる接着写像によって、モジュール Bの出力変 数 sがモジュール Aの入力変数 aと同一視されることにより、モジュール Bとモジュール Aがこの順で結合され、 1つのプログラムが生成される。このとき、モジュール Bの出力 変数とモジュール Aの入力変数の間でデータ型や桁数などが調整される。このプログ ラムの結合は、ホモトビー同値になるように行われるため、必要に応じて結合を解除 して、モジュール Aとモジュール Bを分離することもできる。このように、ソフトウェア開 発支援装置 100は、同値関係をもとにして複数のプログラムモジュールを結合したり 、分離したりすることができ、プログラムモジュールの利用性を高めることができる。
[0151] このように、ソフトウェア開発支援装置 100によれば、同値関係にもとづいてソフトゥ エア部品の合成、置換、連結などの開発工程を線形操作で行うことができるため、ソ フトウェア部品の個数が増えても、開発工数爆発が起きることなぐソフトウェアを効 率良く開発することができる。
[0152] 上記の具体例では、プログラムモジュールの仕様を特徴づける属性として、入出力 インタフェイスを例に挙げ、対応するプログラムモジュール間で入出力インタフェイス の次元や表現形式の不整合を調整することを説明したが、これは属性の一例に過ぎ ない。プログラムモジュールの仕様を特徴づける他の属性の例として、そのプログラム モジュールが参照する変数を考えてもよい。その場合、対応するプログラムモジユー ル間で参照変数の次元や表現形式の不整合が調整される。また、プログラムモジュ ールが利用する関数を属性として考えてもよい。その場合、対応するプログラムモジ ユール間で関数の次元、すなわち関数名や関数の個数などの不整合が調整される。 さらに、その関数の引数や戻り値の次元や表現形式の不整合が調整されてもよい。
[0153] ソフトウェア開発支援装置 100のビューレベル処理ブロック 170は、ソフトウェア開 発者毎に異なるビューを設計してもよい。たとえば、上級のソフトウェア開発者にはプ ログラムモジュールの内部変数の設計変更ができるように、プログラムモジュール内 部のデータ操作が可能なビューを設定する。一方、初級のソフトウェア開発者にはプ ログラムモジュールの外部インタフェイスの設計変更だけを許すように、プログラムモ ジュールの内部のデータ操作が不可能なビューを設定する。このように、開発者のプ ログラミングの経験や技術などのレベルに応じてビューを異ならせてもよい。また、ソ フトウェアを複数の開発者が共同開発する場合、各開発者が担当するプログラムエリ ァに限って設計変更ができるように、開発者毎にビューを異ならせてもよい。後述の ようにソフトウェア開発支援装置 100を保守工程で利用する場合は、ビューレベル処 理ブロック 170は、ソフトウェアの保守者毎に異なるビューを設計してもよい。
[0154] [17]ソフトウェアのライフサイクル管理
ソフトウェア開発のアクティビティには、要求分析、システム設計、プログラム設計、 プログラム実装、単体 ·結合テスト、システムテスト、受け入れテスト、および運用'保 守があり、これらの一連のアクティビティがライフサイクルとして管理される。要求分析 、システム設計、プログラム設計、およびプログラム実装は、ソフトウェアの開発工程 である。開発工程にぉ 、て生成されたソフトウェアのプログラムモジュールにつ！/、て 単体'結合テストが行われ、次にシステム全体の機能面についてシステムテストが行 われ、最終的にシステム出荷時の受け入れテストが行われる。これが試験工程である 。受け入れテストに合格したシステムは運用され、稼働中にシステムが保守される。こ れが保守工程である。
[0155] 図 20に示すソフトウェアライフサイクル管理装置 600は、開発工程から試験工程を 経て、保守工程に至るまでのソフトウェアのライフサイクルを管理する。開発機能プロ ック 610は、既に述べたソフトウェア開発支援装置 100の各機能を有し、抽象階層間 でソフトウェア部品集合の同値関係を不変量として継承しながら、ソフトウェア部品集 合が満たすべき仕様を抽象階層毎にインクリメンタルに詳細化することにより、与えら れた要求仕様に合致するソフトウェアをソフトウェア部品集合力 自動生成する。開 発機能ブロック 610により、ソフトウェアの要求分析力もシステム設計、プログラム設 計、プログラム実装までが実行され、開発されたソフトウェアはソフトウェア記憶部 64 0に記憶される。ソフトウェア記憶部 640は、要求仕様、開発、試験、および保守工程 におけるすべてのプログラムを保持する。
[0156] 試験機能ブロック 620は、開発機能ブロック 610により生成されたソフトウェアが各 抽象階層にお 、て詳細化された仕様に合致する力否かをテストし、問題が発見され た場合に、いずれかの抽象階層において要求条件を修正し、開発機能ブロック 610 は、要求条件が修正された抽象階層から始めて、ソフトウェア部品集合が満たすべき 仕様を抽象階層毎にインクリメンタルに詳細化する。
[0157] 開発されたソフトウェアの試験は、要求分析、システム設計、プログラム設計、およ びプログラム実装のいずれの段階でも行う必要がある。たとえば、試験機能ブロック 6
20が、要求仕様に不具合を発見して修正をしたときは、開発機能ブロック 610は、抽 象階層モデルの位相空間レベルや接着空間レベルなどの上位階層にもどって、そ の階層から設計の詳細化をやり直して不具合を解消する。また、試験機能ブロック 62 0力 プログラム実装において、関数の引数の数や変数のデータ型などに不具合を 発見した場合は、開発機能ブロック 610は、抽象階層モデルのセル空間レベルや表 現レベルなどの下位階層から設計の詳細化をやり直して不具合を解消する。いずれ の階層から作業をやり直すときでも、インクリメンタリモジュラな抽象階層にもとづくソフ トウエア開発支援装置 100によれば、新しい要求条件のもと、線形操作でソフトゥェ ァを再構成することができる。
[0158] 保守機能ブロック 630は、運用中のソフトウェアに修正もしくは機能拡張の必要が あった場合に、その修正もしくは機能拡張を反映すべき抽象階層にお ヽて要求条件 を変更し、開発機能ブロック 610は、要求条件が変更された抽象階層から始めて、ソ フトウェア部品集合が満たすべき仕様を抽象階層毎に再度インクリメンタルに詳細化 する。
[0159] ソフトウェアの保守には、システムの障害への対処もしくは予防のために修正を行う のとして、修正保寸 (corrective maintenance)と予防保寸 (preventive maintenance) があり、システムの機能拡張を行うものとして、改善保守（perfective maintenance)と 適 J心保 (adaptive maintenance)力あ 。
[0160] 修正保守は、現行のシステムに障害が起きた場合に、障害の原因を発見して、ソフ トウエアの必要な修正を行うものである。修正保守は、ソフトウェアの残存不良を修正 する作業であり、一般には仕様の変更はしない。抽象階層モデルを利用した修正保 守は、たとえば、セル空間レベルや表現レベルなど比較的下位の階層で要求条件を 調整して行われる。
[0161] 予防保守は、現実には障害が起きてないが、潜在的な障害の可能性を発見し、シ ステムの故障を未然に防ぐために、システムのある側面を修正、変更することであり、 修正保守と同様に抽象階層モデルを利用して行うことができる。
[0162] 改善保守は、障害を回避するためにソフトウェアを変更するのではなぐシステムの ある機能や性能を向上させるためにソフトウェアの変更を行うことである。改善保守は 、ソフトウェアの仕様の変更を伴うものである。抽象階層モデルを利用した改善保守 は、たとえば位相空間レベルや接着空間レベルなど比較的上位の階層で要求条件 を調整した上で、下位の階層に向けて抽象階層を迪りながら、ソフトウェアを再設計 すること〖こよって行われる。
[0163] 適応保守は、ハードウェアやソフトウェアの技術進歩などの変化に応じてソフトゥェ ァの変更を行うものである。適応保守は、障害に対処するものではなぐ進化していく システムに適応させるために変更を行うものである。適応保守も他の保守と同様に抽 象階層モデルを利用して行うことができる。
[0164] ソフトウェアの保守工程は、新たな要求を分析し、システムとプログラムの設計を評 価し、コードをレビューし、必要に応じて修正を加える点で、ソフトウェアの開発工程 およびソフトウェアの試験工程と共通するアクティビティを含んで 、る。開発工程およ び試験工程が抽象階層モデルを利用して行われるように、保守工程も抽象階層モデ ルを有効に利用して、効率良く行うことができ、保守の負担を軽減することができる。
[0165] 一般に、欠陥修正は別の欠陥修正を引き起こす波及効果がある。保守による手直 しがシステムの別の部分に影響を与えて、新たな障害を生み出すことがあるからであ る。一般的にソフトウェア開発は開発者依存であるため、開発者の作成した仕様書を 丹念にレビューしても保守による影響を正確に予測することは困難である。しかしな がら、本実施の形態のソフトウェアライフサイクル管理装置 600によれば、抽象階層 モデルを利用してソフトウェアの開発が行われ、開発者依存の設計要素が排除され るため、保守においても同じ抽象階層モデルを参照することで、何と何が同値関係に あるかを把握した上で、ある箇所の修正が他の箇所にどのような影響を与えるかを的 確に予測して正しい修正を効率良く行うことができる。
[0166] 修正保守において、ソフトウェアのある部分について同値関係を新たに定義する必 要が生じた場合や、最初力 定義しておくべきであった同値関係が保守段階で発見 された場合でも、抽象階層モデルを参照し、接着空間レベルで同値関係を定義し直 し、その同値関係を下位のセル空間レベルや表現レベルにまで落として実装するこ とにより、整合性を保証することができる。また、拡張保守や適応保守において、ソフ トウエアに新たな機能を追加する場合や、新たなパラメータを設定する場合でも、抽 象階層モデルにおいて適宜新たな同値関係を設定してインクリメンタルにソフトゥェ ァの再設計を行うことができる。また、予防保守において、対応する変数の間でデー タ型ゃデータ長の相違があり、不都合が生じることが予見される場合でも、抽象階層 モデルを利用して、これらの変数に同値関係を定義してその部分について不整合を 調整することができる。
[0167] このように、本実施の形態のソフトウェアライフサイクル管理装置 600によれば、抽 象階層モデルを利用することにより、保守段階で要求の変化が生じても、要求仕様に もとづいて同値関係を定め、設計および実装レベルまでその同値関係を不変量とし て継承して仕様の詳細化と具体ィ匕を図ることができ、変化に対して柔軟かつ効率良く 対応することができる。抽象階層モデルを利用することにより、保守工程におけるソフ トウエアに対する操作も、開発工程における操作と同じように、線形インターオペラビ リティが保証されるため、線形操作で新たな機能の追加や不要な機能の削除を行うこ とがでさる。
[0168] ソフトウェアのライフサイクルモデルとして、ウォーターフォールモデル、ラピッドプロ トタイピングモデル、スパイラルモデルなどいろいろなモデルが提案されている力 本 実施の形態のソフトウェアライフサイクル管理装置 600は、 、ずれかのライフサイクル モデルに依存するものでもなぐまた、いずれかのライフサイクルモデルを前提として 適用されるものでもない。もっとも、本実施の形態のソフトウェアライフサイクル管理装 置 600を!、ずれかのライフサイクルモデルに適合させる形で用いることを妨げな！/、。 本実施の形態のソフトウェアライフサイクル管理装置 600の主要な利点は、インクリメ ンタリモジュラな抽象階層モデルを用いることにより、抽象階層間でソフトウェア部品 集合間の同値関係を不変量として継承して整合性を保証するとともに、ソフトウェア 部品集合の線形統合と線形操作を保証し、ソフトウェアの開発力 試験、保守に至る までのライフサイクルの管理に一貫性をもたせたことにある。
[0169] 以上、実施の形態を説明した。実施の形態は例示であり、さまざまな変形例が可能 であり、そうした変形例も本発明に含まれることは当業者に理解されるところである。 産業上の利用可能性
[0170] 本発明は、ソフトウェアライフサイクル管理の分野に適用することができる。

Claims

請求の範囲
[1] ソフトウェア部品集合間の線形インターオペラピリティを保証するインクリメンタリモ ジユラな抽象階層モデルを利用して、ソフトウェアの開発工程カゝら試験工程を経て、 保守工程に至るまでのライフサイクルを一貫して管理することを特徴とするソフトゥェ ァライフサイクル管理方法。
[2] 前記開発工程は、抽象階層間で前記ソフトウェア部品集合の同値関係を不変量と して継承しながら、前記ソフトウェア部品集合が満たすべき仕様を前記抽象階層毎 にインクリメンタルに詳細化することにより、与えられた要求仕様に合致するソフトゥェ ァを前記ソフトウェア部品集合から自動生成することを特徴とする請求項 1に記載の ソフトウェアライフサイクル管理方法。
[3] 前記試験工程は、前記開発工程により生成された前記ソフトウェアが各抽象階層 にお ヽて詳細化された仕様に合致するカゝ否かをテストし、発見された問題に応じて ヽ ずれかの抽象階層にお!/、て要求条件を修正した上で、その抽象階層から前記開発 工程を繰り返すことにより、前記問題を除去することを特徴とする請求項 2に記載のソ フトウェアライフサイクル管理方法。
[4] 前記保守工程は、運用中の前記ソフトウェアに修正もしくは機能拡張の必要があつ た場合に、その修正もしくは機能拡張を反映すべき抽象階層にお 、て要求条件を変 更した上で、その抽象階層から前記開発工程を繰り返すことにより、前記ソフトウェア の保守を行うことを特徴とする請求項 2または 3に記載のソフトウェアライフサイクル管 理方法。
[5] ソフトウェア部品集合間の線形インターオペラピリティを保証するインクリメンタリモ ジユラな抽象階層モデルを利用した、ソフトウェアの開発機能ブロック、試験機能プロ ック、および保守機能ブロックを備え、ソフトウェアのライフサイクルを前記抽象階層モ デルにもとづいて一貫して管理することを特徴とするソフトウェアライフサイクル管理 装置。
[6] 前記開発機能ブロックは、抽象階層間で前記ソフトウェア部品集合の同値関係を 不変量として継承しながら、前記ソフトウェア部品集合が満たすべき仕様を前記抽象 階層毎にインクリメンタルに詳細化することにより、与えられた要求仕様に合致するソ フトウェアを前記ソフトウェア部品集合力 自動生成することを特徴とする請求項 5に 記載のソフトウェアライフサイクル管理装置。
[7] 前記試験機能ブロックは、前記開発機能ブロックにより生成された前記ソフトウェア が各抽象階層にお 、て詳細化された仕様に合致するか否かをテストし、問題が発見 された場合に、いずれかの抽象階層において要求条件を修正し、前記開発機能プロ ックは、前記要求条件が修正された抽象階層から前記詳細化を繰り返すことを特徴と する請求項 6に記載のソフトウェアライフサイクル管理装置。
[8] 前記保守機能ブロックは、運用中の前記ソフトウェアに修正もしくは機能拡張の必 要があった場合に、その修正もしくは機能拡張を反映すべき抽象階層にお 、て要求 条件を変更し、前記開発機能ブロックは、前記要求条件が変更された抽象階層から 前記詳細化を再度行うことを特徴とする請求項 6または 7に記載のソフトウェアライフ サイクル管理装置。
[9] 前記抽象階層モデルは、各階層においてソフトウェア部品集合に対する操作が可 能にモジュラ化されて構成されており、
前記ソフトウェア部品集合に集合演算を施して、所望の複数のソフトウェア部品集 合を設計する集合設計部と、
前記ソフトウェア部品集合の部分集合を要素とする集合に位相を規定することによ り、前記ソフトウェア部品集合を位相空間として設計する位相空間設計部と、 それぞれが位相空間として設計された前記複数のソフトウェア部品集合の上に同 値関係を規定し、前記同値関係で対応づけられた部分空間を接着した接着空間を 設計する接着空間設計部と、
前記接着空間において前記複数のソフトウェア部品集合に属するソフトウェア部品 の仕様に係る属性をセルで表現し、前記セルの次元を設計するセル空間設計部と、 前記セルの表現形式を設計する表現設計部とを含むことを特徴とする請求項 5から 8のいずれかに記載のソフトウェアライフサイクル管理装置。
[10] 前記モジュラ化された抽象階層モデルは、前記複数のソフトウェア部品集合に関し て、前記ソフトウェアの開発者または保守者に対するビューを設計し、前記開発者ま たは保守者毎に前記複数のソフトウェア部品集合の操作可能範囲を異ならせるビュ 一設計部をさらに含むことを特徴とする請求項 9に記載のソフトウェアライフサイクル 管理装置。
[11] 前記モジュラ化された抽象階層モデルは、前記ソフトウェアの開発、試験、および 保守のいずれかの工程において各設計部による前記ソフトウェア部品集合に対する 操作によって生じた前記ソフトウェア部品集合の変化がホモトビー同値になるように 設計し、前記ソフトウェア部品集合を変化前の状態に戻せるように、その操作手順を 記録するホモトビー設計部をさらに含むことを特徴とする請求項 9または 10に記載の ソフトウェアライフサイクル管理装置。
[12] 前記接着空間設計部は、
互いに素である第 1の位相空間 Xと第 2の位相空間 Yに対して、前記第 2の位相空 間の Yの部分空間 Y力 前記第 1の位相空間 Xへの連続写像を、前記同値関係を
0
表す接着写像 fとして取得する接着写像取得部と、
前記第 2の位相空間 Yの前記部分空間 Yにおける各点 yを、前記接着写像 fによる
0
前記第 1の位相空間 Xにおける像 f (y)と同一視することによって、前記第 2の位相空 間 Yを前記第 1の位相空間に接着し、前記接着空間を同値類の排他的論理和として 取得する等化写像取得部とを含むことを特徴とする請求項 9に記載のソフトウェアラ ィフサイクル管理装置。
[13] 前記セル空間設計部は、
前記接着写像 fによって同一視された前記第 1の位相空間 Xのソフトウェア部品と前 記第 2の位相空間 Yのソフトウェア部品をセル空間において対応づけて接合するセ ル接合部と、
前記セル空間において対応づけられた前記ソフトウェア部品の仕様に係る属性の 次元に関する不整合を調整するセル次元調整部を含むことを特徴とする請求項 12 に記載のソフトウェアライフサイクル管理装置。
[14] 前記表現設計部は、前記セル空間にお 、て対応づけられた前記ソフトウェア部品 の仕様に係る属性の表現形式に関する不整合を受容表現にしたがって調整する表 現形式調整部を含むことを特徴とする請求項 13に記載のソフトウェアライフサイクル 管理装置。
PCT/JP2005/010355 2004-06-15 2005-06-06 ソフトウエアライフサイクル管理方法およびソフトウエアライフサイクル管理装置 WO2005124541A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004176444A JP2006003939A (ja) 2004-06-15 2004-06-15 ソフトウエアライフサイクル管理方法およびソフトウエアライフサイクル管理装置
JP2004-176444 2004-06-15

Publications (1)

Publication Number Publication Date
WO2005124541A1 true WO2005124541A1 (ja) 2005-12-29

Family

ID=35509887

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/010355 WO2005124541A1 (ja) 2004-06-15 2005-06-06 ソフトウエアライフサイクル管理方法およびソフトウエアライフサイクル管理装置

Country Status (2)

Country Link
JP (1) JP2006003939A (ja)
WO (1) WO2005124541A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007188334A (ja) * 2006-01-13 2007-07-26 Kanazawa Inst Of Technology システム統合装置
US9129291B2 (en) * 2008-09-22 2015-09-08 Personics Holdings, Llc Personalized sound management and method
JPWO2011068015A1 (ja) * 2009-12-02 2013-04-18 コニカミノルタホールディングス株式会社 システム構築支援方法

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0594483A (ja) * 1991-10-02 1993-04-16 Nec Software Ltd 表データの結合方式
JPH05127959A (ja) * 1991-11-07 1993-05-25 Fujitsu Ltd 異種データベース間のデータ結合装置
JPH06202859A (ja) * 1991-02-26 1994-07-22 Texas Instr Inc <Ti> システム設計の方法および装置
JPH0916392A (ja) * 1995-06-27 1997-01-17 Mitsubishi Electric Corp ソフトウェア開発支援方式
JP2000155857A (ja) * 1998-09-14 2000-06-06 Monorisu:Kk 対象物の多次元的定義方法および装置
JP2002312376A (ja) * 2001-04-17 2002-10-25 Kanazawa Inst Of Technology 電子商取引支援方法とシステム、およびそれらに利用可能なビジネス情報管理システム
JP2002342080A (ja) * 2001-05-16 2002-11-29 Fujitsu Ltd ソフトウェア開発支援装置及びプログラム
JP2003271698A (ja) * 2002-03-18 2003-09-26 Maeda Corp 建設工事データの検索方法
JP2004086782A (ja) * 2002-08-29 2004-03-18 Hitachi Ltd 異種データベース統合支援装置

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06202859A (ja) * 1991-02-26 1994-07-22 Texas Instr Inc <Ti> システム設計の方法および装置
JPH0594483A (ja) * 1991-10-02 1993-04-16 Nec Software Ltd 表データの結合方式
JPH05127959A (ja) * 1991-11-07 1993-05-25 Fujitsu Ltd 異種データベース間のデータ結合装置
JPH0916392A (ja) * 1995-06-27 1997-01-17 Mitsubishi Electric Corp ソフトウェア開発支援方式
JP2000155857A (ja) * 1998-09-14 2000-06-06 Monorisu:Kk 対象物の多次元的定義方法および装置
JP2002312376A (ja) * 2001-04-17 2002-10-25 Kanazawa Inst Of Technology 電子商取引支援方法とシステム、およびそれらに利用可能なビジネス情報管理システム
JP2002342080A (ja) * 2001-05-16 2002-11-29 Fujitsu Ltd ソフトウェア開発支援装置及びプログラム
JP2003271698A (ja) * 2002-03-18 2003-09-26 Maeda Corp 建設工事データの検索方法
JP2004086782A (ja) * 2002-08-29 2004-03-18 Hitachi Ltd 異種データベース統合支援装置

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
HAYAKAWA K. ET AL: "Cell Model ni yoru, Cyber Sekai no Joho Modeling", INFORMATION PROCESSING SOCIETY OF JAPAN KENKYU HOKOKU, INFORMATION PROCESING SOCIETY OF JAPAN, vol. 2002, no. 3, 22 January 2002 (2002-01-22), pages 97 - 104, XP002994415 *
KATO E. ET AL: "Knowledge Database Kochiku Shinhoshiki no Ikkosatsu - Cell Database no Tekiyo", INFORMATION PROCESSING SOCIETY OF JAPAN KENKYU HOKOKU, INFORMATION PROCESSING SOCIETY OF JAPAN, vol. 2003, no. 1, 16 January 2003 (2003-01-16), pages 13 - 18, XP002994414 *
KODAMA T. ET AL: "A Development of Cellular Database on an Incrementally modular abstraction hierarchy", INFORMATION PROCESSING SOCIETY OF JAPAN KENKYU HOKOKU, INFORMATION PROCESSING SOCIETY OF JAPAN, vol. 2004, no. 3, 16 January 2004 (2004-01-16), pages 121 - 128, XP002994413 *
KUNII T.L. AND HISADA M.: "Overcoming software complexity by constructing abstraction hierarchies: the principles and applications", PROCEEDINGS OF THE SIXTH INTERNATIONAL CONFERENCE ON ENGINEERING OF COMPLEX COMPUTER SYSTEMS (ICECCS 2000), 14 September 2000 (2000-09-14), pages 126 - 130, XP010514176 *
KUNII T.L. ET AL: "Modeling of Conceptual Multiresolution Analysis by an Incrementally Modular Abstraction Hierarchy", IEICE TRANSACTIONS ON INFORMATION AND SYSTEMS, vol. E86-D, no. 7, July 2003 (2003-07-01), pages 1181 - 1190, XP001178466 *
KUNII T.L.: "Algebraic Topological Modeling for Cyberworld Design", PROCEEDINGS OF THE 2003 INTERNATIONAL CONFERENCE ON CYBERWORLDS, IEEE, 5 December 2003 (2003-12-05), pages XIX - XXV, XP010674990 *

Also Published As

Publication number Publication date
JP2006003939A (ja) 2006-01-05

Similar Documents

Publication Publication Date Title
Atkinson Component-based product line engineering with UML
Crnkovic et al. Implementing and integrating product data management and software configuration management
Acher et al. A domain-specific language for managing feature models
CN115510563B (zh) 一种基于模型的产品研制流程设计方法及装置
Wilking et al. Integrating machine learning in digital twins by utilizing sysml system models
WO2005124541A1 (ja) ソフトウエアライフサイクル管理方法およびソフトウエアライフサイクル管理装置
Vitharana et al. Research issues in testing business components
Arbab et al. Integrating architectural models-symbolic, semantic and subjective models in enterprise architecture
US11188307B2 (en) Modelizing resources and external data of a program for procedural language coding
Mannion et al. Using viewpoints to define domain requirements
León et al. Model-to-model transformation: From uml class diagrams to labeled property graphs
Kulkarni et al. Towards business application product lines
Wojszczyk et al. The process of verifying the implementation of design patterns—used data models
US20050154976A1 (en) Method and system for automated metamodel system software code standardization
Nešic et al. Applying multi-level modeling to data integration in product line engineering
JP2005092855A (ja) ソフトウエア開発支援装置およびソフトウエア開発支援方法
Silva et al. Revisiting requirement engineering for intelligent manufacturing
Herzog An approach to systems engineering tool data representation and exchange
WO2005109190A1 (ja) ソフトウエア開発支援装置およびソフトウエア開発支援方法
Simonin et al. Automatized integration of a contextual model into a process with data variability
Whitman et al. Issues encountered between model views
JP2007188334A (ja) システム統合装置
Mili et al. Towards a methodology for representing and classifying business processes
WO2005106651A1 (ja) 情報設計装置および情報設計方法
CN117785157B (zh) 一种基于金融风控业务规则场景的决策引擎及实现方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase