JP2006235899A - Uml model preparation support method and its system - Google Patents
Uml model preparation support method and its system Download PDFInfo
- Publication number
- JP2006235899A JP2006235899A JP2005048284A JP2005048284A JP2006235899A JP 2006235899 A JP2006235899 A JP 2006235899A JP 2005048284 A JP2005048284 A JP 2005048284A JP 2005048284 A JP2005048284 A JP 2005048284A JP 2006235899 A JP2006235899 A JP 2006235899A
- Authority
- JP
- Japan
- Prior art keywords
- change
- uml model
- uml
- changes
- history
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
Description
本発明は、コンピュータソフトウェアを開発する作業においてUMLを用いて要求分析/システム設計作業、及びそれらの仕様書作成を支援するUMLモデル作成支援方法及びその装置に関する。 The present invention relates to a UML model creation support method and apparatus for supporting requirements analysis / system design work using UML and creation of specifications thereof in the work of developing computer software.
一般的にソフトウェア開発は、要求分析、システム設計、実装、テスト、移行などのフェーズに分類される。このため、ソフトウェア開発者は、それぞれのフェーズで開発対象のソフトウェアをそれぞれの役割に分かれて開発を行う。 Software development is generally classified into phases such as requirements analysis, system design, implementation, testing, and migration. For this reason, the software developer develops the software to be developed in each phase in each phase.
要求分析とは、ソフトウェアを作りたいと考えている者(要求者)の考えを汲み取り、その要求を満たすためには、ソフトウェアがどのような機能を備えるべきかを分析することである。 Requirement analysis is the analysis of what functions software should have to meet the requirements of the person (requester) who wants to create software.
システム設計では、分析して導き出された機能を実現するには、ソフトウェアがどのような構成をしていて、どのようにふるまう必要があるのかを検討する。 System design considers how the software is configured and how it behaves in order to achieve the functions derived from the analysis.
上記の要求分析、システム設計では、しばしぱモデリングと称される手法が有効であるとされている。それは、文章だけではなく、図を用いてシステムの静的な側面と動的な側面を表現することで、システムに対する理解が深まるからである。そのモデリングのための言語として、UML(Unified Modeling Language)が提案されている。
ソフトウェア開発において、UMLを用いて要求分析やシステム設計をすることが多くなってきており、この場合、開発者はUMLを用いてシステムをモデリングすることで、要求分析及びシステム設計を行う。 In software development, UML is often used for requirements analysis and system design. In this case, the developer performs requirements analysis and system design by modeling the system using UML.
しかし、一般的にUMLモデルはシステムの多様な側面を多数の図で表現しているため、作成の難易度が高く、管理が困難である。その結果、UMLモデルを作成する際、誤りや矛盾を含んでしまう可能性があった。 However, since the UML model generally expresses various aspects of the system with a large number of diagrams, it is difficult to create and difficult to manage. As a result, when creating a UML model, there is a possibility that errors and contradictions are included.
誤りや矛盾が発生する原因の1つとして、UMLで定義されている図が多数あるだけではなく、システムの1つの機能やその相関関係を表現するために複数の図が必要で、お互いに複雑な関係性を持っていることが挙げられる。 As one of the causes of errors and contradictions, not only are there many figures defined in UML, but multiple figures are necessary to express one function of the system and its correlation, and they are complicated to each other. Have a strong relationship.
このため、複数のUML図の関係性を明確にし、誤りや矛盾の発生を防ぎ、開発者が容易に短期間でUMLモデルを作成できるように支援する仕組みが必要である。 Therefore, there is a need for a mechanism that clarifies the relationship between a plurality of UML diagrams, prevents the occurrence of errors and contradictions, and supports the developer to easily create a UML model in a short period of time.
本発明は上記の問題点に鑑みてなされたものであり、その目的とするところは、複数のUML図の関係性を明確にして誤りや矛盾の発生を防ぐことができるUMLモデル作成支援方法及びその装置を提供することである。 The present invention has been made in view of the above problems, and an object of the present invention is to provide a UML model creation support method capable of clarifying the relationship between a plurality of UML diagrams and preventing occurrence of errors and contradictions. It is to provide such a device.
本発明は上記の目的を達成するために、コンピュータ装置を使用してUMLを用いて要求分析或いはシステム設計を行う場合のUMLモデル作成支援方法であって、前記コンピュータ装置は、UMLモデルが、図と要素と関係とから構成されるものとした定義を記憶していると共に、UMLモデルの変更とは、UMLモデルを構成する図と要素と関係のうちの少なくとも何れか1つを追加或いは削除或いは更新することであるとした定義を記憶し、上記の定義に基づいて、作成中のUMLモデルに対して行われた変更に関する情報を変更履歴として記録するUMLモデル作成支援方法を提案する。 In order to achieve the above object, the present invention provides a UML model creation support method in the case where requirements analysis or system design is performed using UML using a computer device. And a definition that is made up of an element and a relationship, and a change in the UML model means adding or deleting at least one of a diagram, an element, and a relationship constituting the UML model, or We propose a UML model creation support method that stores a definition that is to be updated and records information about changes made to the UML model being created as a change history based on the above definition.
本発明のUMLモデル作成支援方法によれば、ソフトウェア開発者がコンピュータ装置を使用してUMLを用いて要求分析或いはシステム設計を行っている際に、コンピュータ装置は、UMLモデルが図と要素と関係とから構成されるものとした定義と、UMLモデルの変更とはUMLモデルを構成する図と要素と関係のうちの少なくとも何れか1つを追加或いは削除或いは更新することであるとした定義とに基づいて、UMLモデルの変更に関する情報を変更履歴として記録する。 According to the UML model creation support method of the present invention, when a software developer uses UML to perform requirements analysis or system design using a computer device, the computer device has a relationship between the UML model and the figure and elements. And the definition that the change of the UML model is the addition, deletion, or update of at least one of the diagrams and elements that make up the UML model. Based on this, information on the change of the UML model is recorded as a change history.
これにより、UMLモデルを構成する図と要素と関係のうちの少なくとも何れか1つが追加或いは削除或いは更新されると、この変更に関する情報が変更履歴として記録される。 As a result, when at least one of diagrams, elements, and relationships constituting the UML model is added, deleted, or updated, information regarding the change is recorded as a change history.
また、本発明は上記の目的を達成するために、UMLを用いて要求分析或いはシステム設計を行う場合のコンピュータ装置からなるUMLモデル作成支援装置であって、UMLモデルが図と要素と関係とから構成されるものとした定義と、UMLモデルの変更とはUMLモデルを構成する図と要素と関係のうちの少なくとも何れか1つを追加或いは削除或いは更新することであるとした定義を記憶する記憶手段と、上記の定義に基づいて、作成中のUMLモデルに対して行われた変更に関する情報を変更履歴として記録する変更履歴記録手段とを備えているUMLモデル作成支援装置を提案する。 Further, in order to achieve the above object, the present invention is a UML model creation support device comprising a computer device in the case of performing requirements analysis or system design using UML. A memory for storing a definition that is to be configured and a definition that a change in the UML model is to add, delete, or update at least one of the diagrams and elements that make up the UML model Proposed is a UML model creation support apparatus comprising means and a change history recording means for recording information on changes made to a UML model being created as a change history based on the above definition.
本発明のUMLモデル作成支援装置によれば、ソフトウェア開発者がUMLを用いて要求分析或いはシステム設計を行っている際に、UMLモデルが図と要素と関係とから構成されるものとした定義と、UMLモデルの変更とはUMLモデルを構成する図と要素と関係のうちの少なくとも何れか1つを追加或いは削除或いは更新することであるとした定義とに基づいて、UMLモデルの変更に関する情報を変更履歴として記録する。 According to the UML model creation support apparatus of the present invention, when a software developer performs a requirement analysis or system design using UML, the definition that the UML model is composed of diagrams, elements, and relationships The change of the UML model is based on the diagram that constitutes the UML model and the definition that it is to add, delete, or update at least one of the elements and the relationship. Record as change history.
これにより、UMLモデルを構成する図と要素と関係のうちの少なくとも何れか1つが追加或いは削除或いは更新されると、この変更に関する情報が変更履歴として記録される。 As a result, when at least one of diagrams, elements, and relationships constituting the UML model is added, deleted, or updated, information regarding the change is recorded as a change history.
本発明によれば、上記の方法及び装置により支援を受けずにUMLモデルを作成していた従来の場合には、UMLモデルを変更しなければならなかった部分を見落としてUMLモデルの整合性を保てなくなり、誤りや矛盾が発生したり、後にその整合性を合わせようとして手戻りが発生したが、上記の方法及び装置によって支援を受けることにより、これらの誤りや矛盾及び手戻りの発生を防ぐことができ、ソフトウェア開発者はUMLモデルを容易に短期間で作成することができるようになる。 According to the present invention, in the conventional case where the UML model was created without assistance by the above method and apparatus, the consistency of the UML model was overlooked by overlooking the part that had to be changed. However, errors or contradictions occur, or rework occurs to try to match the consistency later, but with the assistance of the above method and device, these errors, contradictions, and rework occur. Software developers can easily create UML models in a short period of time.
以下、図面を参照して本発明の一実施形態を説明する。 Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
本実施形態では、UMLモデルが繰り返し変更され、洗練されていくという性質を利用し、UMLモデル作成を支援する方法を構築すると共に、この方法を実施する装置を構成した。 In the present embodiment, a method for supporting creation of a UML model is constructed by utilizing the property that the UML model is repeatedly changed and refined, and an apparatus for implementing this method is configured.
本実施形態では、まず、図1の表に示すようにUMLモデルの構成やUMLモデルの変更を定義する。即ち、一般的にUMLでは、クラス図、オブジェクト図、パッケージ図、ユースケース図、コラボレーション図、ステートチャート図、アクティビティ図、コンポーネント図、配置図の9種類の図を定義している。 In this embodiment, first, as shown in the table of FIG. 1, the configuration of the UML model and the change of the UML model are defined. That is, generally, UML defines nine types of diagrams: class diagrams, object diagrams, package diagrams, use case diagrams, collaboration diagrams, state chart diagrams, activity diagrams, component diagrams, and layout diagrams.
本実施形態において、UML図中に記述するものは、「要素」と「関係」の2種類であると定義する。「要素」には、図1の表に記載したものがあり、この表に記載した付属情報を保持する。また、「要素」の付属情報である操作/属性は、操作/属性の付属情報を保持する。「関係」は、図1の表に記載したものがあり、この表に記載した付属情報を保持する。 In this embodiment, what is described in the UML diagram is defined as two types of “element” and “relation”. “Elements” include those described in the table of FIG. 1, and hold the auxiliary information described in this table. Further, the operation / attribute which is the attached information of “element” holds the attached information of the operation / attribute. “Relationship” is described in the table of FIG. 1 and holds the auxiliary information described in this table.
即ち、図1に示すように、「要素」としては、クラス、オブジェクト、パッケージ、ユースケース、アクタ、インターフェース、N項関連、アクティビティ、状態、初期状態、終了状態、履歴状態、連結点、動的選択点、フォーク、ジョイン、分岐、コントロールアイコン(イベント送信)、コントロールアイコン(イベント受信)、コンポーネント、ノードが定義される。 That is, as shown in FIG. 1, “elements” include classes, objects, packages, use cases, actors, interfaces, N-term relations, activities, states, initial states, end states, history states, connection points, dynamic points. Selection points, forks, joins, branches, control icons (event transmission), control icons (event reception), components, and nodes are defined.
また、「関係」としては、関連、リンク、集約、コンポジション、汎化、依存、実現、メッセージ、遷移、コントロールフロー、オブジェクトフローが定義される。 In addition, as “relation”, association, link, aggregation, composition, generalization, dependence, realization, message, transition, control flow, and object flow are defined.
さらに、「要素」の付属情報としては、名前、属性、操作、ステレオタイプ、entryアクション、exitアクション、doアクション、includeアクション、活性区間、生存線が定義される。 Furthermore, as the attached information of “element”, name, attribute, operation, stereotype, entry action, exit action, do action, include action, active section, and lifeline are defined.
「関係」の付属情報としては、名前、ステレオタイプ、ロール名(親/子)、多重度(親/子)、関連名の方向、親子の方向、引数、戻り値、メッセージ線、トリガ、ガード、アクションが定義される。 Attached information of "Relation" includes name, stereotype, role name (parent / child), multiplicity (parent / child), direction of related name, parent-child direction, argument, return value, message line, trigger, guard , Actions are defined.
操作の付属情報としては、名前、引数、戻り値、可視性、クラス操作(static)が定義される。 Names, arguments, return values, visibility, and class operations (static) are defined as attached information of operations.
属性の付属情報としては、名前、型、初期値、可視性、クラス属性(static)が定義される。 As attribute attribute information, name, type, initial value, visibility, and class attribute (static) are defined.
また、「関係」は方向を持ち、方向を親・子と称する。UMLモデルを構成する構成物の関係は図2のようになり、「図」に対して「要素」と「関係」が従属し、これらの「要素」と「関係」のそれぞれに「付属情報」が従属する。 The “relation” has a direction, and the direction is called a parent / child. The relationship of the constituents that make up the UML model is as shown in FIG. 2. “Element” and “Relation” are subordinate to “Figure”, and “Attachment information” is assigned to each of “Element” and “Relation”. Is subordinate.
本発明では、図3の表に示すように、UMLモデルの変更を、図の追加或いは削除或いは更新(以下、追加/削除/更新と記す)、要素の追加/削除/更新、関係の追加/削除/更新のいずれかの変更操作のことであると定義する。 In the present invention, as shown in the table of FIG. 3, the change of the UML model is the addition, deletion or update of the diagram (hereinafter referred to as addition / deletion / update), the addition / deletion / update of elements, the addition / It is defined as a change operation of either deletion / update.
図の追加とは、図を新規に作成することである。同様に図の削除は、図を削除することである。図の更新とは、新たに要素や関係を追加すること、既に図に記載されている要素や関係を削除或いは更新(以下、削除/更新と記す)すること、あるいは図の種別を変更することである。 Adding a figure means creating a new figure. Similarly, deleting a figure is deleting a figure. Updating a diagram means adding a new element or relationship, deleting or updating an element or relationship already described in the diagram (hereinafter referred to as deletion / update), or changing the type of the diagram. It is.
要素の追加とは、要素を新規に作成することである。同様に要素の削除は、要素を削除することである。要素の更新とは、要素が保持する付属情報(名前、属性、操作、ステレオタイプ、entryアクション、exitアクション、doアクション、includeアクション、活性区間、生存線)を追加/削除/更新すること、あるいは要素の種別を変更することである。 Adding an element means creating a new element. Similarly, deleting an element is deleting an element. Updating an element means adding / deleting / updating attached information (name, attribute, operation, stereotype, entry action, exit action, do action, include action, active section, lifeline) held by the element, or It is to change the element type.
関係の追加とは、関係を新規に作成することである。同様に関係の削除は、関係を削除することである。関係の更新とは、関係が保持する付属情報(名前、多重度(親/子)、ロール名、関連名の方向、親子の向き、ステレオタイプ、引数、戻り値、メッセージ線、トリガ、ガード、アクション)を追加/削除/更新すること、あるいは関係の種別を変更することである。 Adding a relationship means creating a new relationship. Similarly, deleting a relationship is deleting a relationship. Relationship update means attached information (name, multiplicity (parent / child), role name, direction of related name, parent / child orientation, stereotype, argument, return value, message line, trigger, guard, Action) is added / deleted / updated, or the type of relationship is changed.
要素の更新の中で、特別に操作/属性の更新はより詳細に、操作/属性の付属情報(名前、引数、戻り値、可視性、クラス操作(static)またはクラス属性(static))を追加/削除/更新することであると定義する。 In the update of an element, special operation / attribute update is added in more detail, and additional information of the operation / attribute (name, argument, return value, visibility, class operation (static) or class attribute (static)) is added. / Deletion / update.
また、全ての変更は、変更操作・変更対象・変更内容・パラメータ・ターゲットで構成される。パラメータは、追加される場合は追加される情報、更新の場合は更新される情報を格納する。ただし、削除の場合は空欄である。ターゲットは、更新される場合は更新対象の情報、削除される場合は削除対象の情報を格納する。ただし、追加の場合は空欄である。 All changes are made up of a change operation, a change target, change contents, parameters, and a target. The parameter stores information to be added when added and information to be updated when updated. However, it is blank for deletion. The target stores information to be updated when updated, and information to be deleted when deleted. However, it is blank when adding.
次に、本実施形態では、UMLモデルが変更された過程を追跡可能な履歴を記録する方法を定義している。ここで、UMLモデルの変更を追跡する意味について説明する。UMLモデルの変更を行った時、その変更を行った影響で別の変更が発生する場合がある。それは、UMLモデルの一部を変更したことで別の部分との整合性を取れなくなるからである。例えぱ、図4に示すように、UML図Aを変更したとき、整合性を保つためにUML図Bを変更したとする。このとき、同様にUML図Cも変更しなければなかったが、開発者はそれに気づかず見落としてしまうと、後になって整合性を取るために手戻りが発生してしまうことになる。 Next, in this embodiment, a method for recording a history capable of tracking the process of changing the UML model is defined. Here, the meaning of tracking the change of the UML model will be described. When the UML model is changed, another change may occur due to the effect of the change. This is because a part of the UML model is changed so that consistency with another part cannot be obtained. For example, as shown in FIG. 4, when the UML diagram A is changed, it is assumed that the UML diagram B is changed in order to maintain consistency. At this time, the UML diagram C had to be changed in the same manner. However, if the developer does not notice it and overlooks it, a rework will occur for later consistency.
つまり、UML図Aの変更は、UML図B及びUML図Cに対して影響を与え、これらの図に変更を発生させていることになり、本実施形態ではそのような変更の影響が伝播する関係を、追跡できるように変更履歴として定義している。 That is, the change in the UML diagram A affects the UML diagram B and the UML diagram C, and changes are generated in these diagrams. In the present embodiment, the effect of such a change propagates. Relationships are defined as change history so that they can be tracked.
通常、変更履歴は図5のような木構造になる。例えば、変更101を行ったことによる影響により変更111〜113が生じた場合、これらの変更の関係を変更履歴として記録する。さらに、変更111を行ったことによる影響により変更121が生じた場合、変更112を行ったことによる影響により変更122,123が生じた場合、変更113を行ったことによる影響により変更124,125が生じた場合にはこれらの変更の関係を変更履歴として記録する。
Normally, the change history has a tree structure as shown in FIG. For example, when changes 111 to 113 occur due to the effect of the
次に、以上のような定義及び変更履歴を用いて、UMLモデルの作成を支援する方法及びその装置の一実施形態について説明する。本実施形態では、図6に示すように、UMLモデル作成部11、変更履歴記録部12、変更推測部13、変更履歴データベース(以下、変更履歴DBと称する)14、キーボードやマウス等からなる操作部15、モニターディスプレイを含む表示部16を備えたコンピュータ装置によってUMLモデル作成支援システム10を構成した。尚、UMLモデル作成支援システム10は予め設定されているコンピュータプログラムによって動作する。
Next, an embodiment of a method and apparatus for supporting creation of a UML model using the above definition and change history will be described. In the present embodiment, as shown in FIG. 6, an operation including a UML
(UMLモデル作成)
UMLモデル作成部11は、UMLモデル作成を担当し、UMLモデルが図と要素と関係とから構成されるものとした定義を記憶しており、通常のUMLモデル作成機能に加えて、本実施形態において作成支援のために利用する情報入力の補助、本実施形態によって得られた情報を出力する機能を持つ。
(Create UML model)
The UML
(変更履歴記録)
変更履歴記録部12は、UMLモデルの変更とはUMLモデルを構成する図と要素と関係のうちの少なくとも何れか1つを追加或いは削除或いは更新することであるとした定義を記憶しており、上記のように定義した変更履歴記録方法を用いて変更履歴を変更履歴DB14に記録する。
(Change log recording)
The change
UMLモデル作成支援システム10の各部は図7に示すように動作する。即ち、開発者が操作部15を介してUMLモデル作成部11において作成しているUMLモデルに変更を加えたとき、変更されたUMLモデル21に関する変更を変更履歴記録部12が変更履歴DB14に記録する。
Each unit of the UML model
変更を記録する方法は、事前に変更履歴記録部12が、自動的に記録するように設定しておく方法と開発者が変更を行ったときにこの変更を記録するように明示的に選択する方法の二種類があり、これらの何れかを操作部15から設定できるようになっている。
The change log recording method is set in advance so that the change
自動的に記録する場合は、開発者がUMLモデルを変更したときに、変更履歴記録部12はその変更を自動的に変更履歴DB14に記録した後、直前に行った変更(既に変更履歴として記録されていた変更22)から影響を受けていると判断し、直前に行った変更22と今行った変更(変更されたUMLモデル21から作成した変更23)との依存関係を変更履歴DB14に記録する。開発者が明示的に変更を記録した場合は、変更履歴記録部12はその変更23を変更履歴DB14に記録した後、開発者が変更履歴DB14の中から影響を受けている変更22を選択し、変更履歴記録部12が影響を受けている変更22と今行った変更23との依存関係を変更履歴DB14に記録する。
In the case of automatic recording, when the developer changes the UML model, the change
変更履歴記録処理の全体の流れは、図8に示す通りである。即ち、開発者が操作部15を介してUMLモデル作成部11において作成しているUMLモデルに変更を加えたとき(SA1)、UMLモデル作成部11は変更自動記録に設定されているか否かを判定し(SA2)、変更自動記録に設定されているときは、変更履歴記録部12によって、上記加えられた変更23の変更操作と、変更対象、変更内容、パラメータ、及びターゲットを変更履歴DB14に記録する(SA3)と共に、この変更23と直前に行った変更22との依存関係を変更履歴DB14に記録する(SA4)。
The overall flow of the change history recording process is as shown in FIG. That is, when the developer makes a change to the UML model created in the UML
また、前記SA2の判定の結果、変更自動記録に設定されておらずに開発者が変更記録を行うように設定されているときは、変更履歴記録部12によって、開発者が明示的に選択した変更23、すなわち開発者が記録するものとして選択した変更操作、変更対象、変更内容、パラメータ、及びターゲットを変更履歴DB14に記録し(SA6)、さらに変更履歴記録部12は、影響を受けた変更22が変更履歴DB14に存在するか否かを判定し(SA7)、存在するときは影響を受けた変更22と開発者が明示的に選択した変更23との依存関係を変更履歴DB14に記録する(SA8)。
In addition, if the developer is set to record changes without being set to automatic change recording as a result of the determination of SA2, the change
(変更推測)
変更推測部13は、図9に示すように、作成中のUMLモデルに対して新たに変更が加えられたときに動作する。即ち、開発者が操作部15を介してUMLモデル作成部11において作成しているUMLモデルに対して新たに変更を加えたとき、新たに加えられた変更31によって発生する可能性がある変更32を変更推測部13が推測して作成し、これを表示部16を介して開発者に提示する。
(Change guess)
As shown in FIG. 9, the
変更推測部13を動作させる方法としては、事前に新たに変更が加えられたときに変更推測部13が自動的に推測を行うように設定しておく方法とソフトウェア開発者が変更推測部13に推測するように指示する方法の二種類の方法があり、これらの何れかを操作部15から設定できるようになっている。
There are two methods for operating the change inference unit 13: a method in which the
変更推測部13は予め定義された変更の類似度に関する情報を記憶しており、変更推測部13が動作を開始すると、変更推測部13は、新たに加えられた変更31と類似している変更33を変更履歴DB14から検索する。ここでの検索とは、変更履歴DB14に記録されている変更の類似度を図10のフローチャートに示す手順で判定し、予め定義した類似度に基づく判定基準を満たしている変更を、類似している変更として取得することである。尚、予め定義した類似度及びこれに基づく判定基準は、変更推測部13に予め記憶されている。
The
即ち、図10のフローチャートに示すように、変更推測部13は変更の類似度を判定する際に、先ず、変更操作が一致しているか否かを判定し(SB1)、一致していないときは類似していないものとして類似度の判定処理を終了する。また、変更操作が一致しているときは、変更対象が一致しているか否かを判定し(SB2)、変更対象が一致しているときは、変更内容が一致しているか否かを判定する(SB3)。この判定の結果、変更内容が一致しているときのみ、この変更を類似している変更として取得する(SB4)。
That is, as shown in the flowchart of FIG. 10, when determining the similarity of change, the
また、前記SB2の判定の結果、変更対象が一致していないときは、変更推測部13は、変更対象の種別が一致しているか否かを判定し(SB5)、変更対象の種別が一致していないときは、類似していないものとして類似度の判定処理を終了する。また、変更対象の種別が一致しているときは、変更内容が一致しているか否かを判定し(SB6)、変更内容が一致していないときは、類似していないものとして類似度の判定処理を終了する。また、変更内容が一致しているときは、この変更を類似している変更として取得する(SB7)。
If the result of determination in SB2 indicates that the change targets do not match, the
2つの変更が類似していると判定する基準は、「変更操作」、「変更対象」、「変更対象の種別」、「変更内容」が一致しているか否かである。ただし、類似している変更は、変更履歴DB14の中に複数存在する場合がある。
The criterion for determining that two changes are similar is whether or not the “change operation”, “change target”, “change target type”, and “change contents” match. However, there may be a plurality of similar changes in the
以下に判定基準を満たす場合の一例を挙げて説明する。「変更操作が一致」という判定基準は、例えば、変更操作が「追加」の変更に類似している変更を取得しようとしているときには、同じ「追加」を行っている変更がその基準を満たしていると判定する。「削除」及び「更新」の変更操作に関しても同様である。 An example in the case where the determination criteria are satisfied will be described below. For example, when the change operation is about to acquire a change similar to the change of “add”, the change that is performing the same “add” satisfies the criterion. Is determined. The same applies to the change operation of “delete” and “update”.
「変更対象が一致」という判定基準は、例えば、UMLモデルの要素「クラス」の中の1つである「装置クラス」を変更対象としている変更に類似している変更を取得しようとしているときには、同じ「装置クラス」を変更対象としている変更がその基準を満たしていると判定する。 The determination criterion “change target matches” is, for example, when acquiring a change similar to a change whose change target is “device class” which is one of the elements “class” of the UML model. It is determined that changes for which the same “device class” is to be changed satisfy the criteria.
「変更対象の種別が一致」という判定基準は、例えば、UMLモデルの要素「クラス」の中の1つである「装置クラス」を変更対象としている変更に類似している変更を取得しようとしているときには、同じ種別のUMLモデルの要素「クラス」を変更対象としている変更がその基準を満たしていると判定する。 The criterion of “matching type of change target” is, for example, trying to acquire a change similar to a change whose change target is “device class” which is one of the elements “class” of the UML model. In some cases, it is determined that a change for which the element “class” of the UML model of the same type satisfies the criteria.
「変更内容が一致」という判定基準は、例えば、UMLモデルの要素に対する変更内容「名前を更新する」の変更操作を行っている変更を取得しようとしているときには、同じ「名前を更新する」の変更内容の変更を行っている変更がその基準を満たしていると判定する。 For example, when the user is trying to acquire a change in which a change operation “update name” is performed on an element of the UML model, the same “update name” change criterion is used. It is determined that the change that is changing the content satisfies the criteria.
また、変更推測部13は検索の結果、複数の類似した変更を取得する場合があり、それぞれの変更について以下のように動作する。
Further, the
変更推測部13は、検索した結果類似していると判定された変更33から影響が伝播した変更34を追跡する。影響された変更が1つ以上存在するならば、変更推測部13は追跡した変更34のパラメータおよびターゲットと新たに加えられた変更31のパラメータおよびターゲットを入れ替え、新たに加えられた変更31の後に発生する可能性がある変更32を推測して作成し、これを表示部16を介して開発者に提示する。
The
変更推測処理の全体の流れは、図11のフローチャートに示す通りである。即ち、開発者が操作部15を介してUMLモデル作成部11において作成しているUMLモデルに変更を加えたとき(SC1)、変更推測部13は変更自動推測に設定されているか否かを判定し(SC2)、変更自動推測に設定されていないときは後述するSC9の処理に移行し、変更自動推測に設定されているときは、変更推測部13が類似している変更を変更履歴DB14から取得し(SC3)、取得した変更が1つ以上であるか否かを判定する(SC4)。
The overall flow of the change estimation process is as shown in the flowchart of FIG. That is, when the developer makes a change to the UML model created in the UML
この判定の結果、取得した変更がない場合は処理を終了し、取得した変更が1つ以上存在する場合は、変更推測部13が取得した変更33(複数ある場合はそれぞれの変更)に基づいて影響された変更を追跡する(SC5)。この後、変更推測部13は、追跡して得られた変更34が1つ以上存在するか否かを判定し(SC6)、存在しないときは処理を終了し、追跡して得られた変更34が1つ以上存在するときは、変更推測部13が追跡して得られた変更34のパラメータおよびターゲットを、新たに行った変更31のパラメータおよびターゲットと入れ替えて、発生する可能性がある変更32を作成し(SC7)、作成した変更32を表示部16を介して開発者に提示する(SC8)。
As a result of this determination, if there is no acquired change, the process is terminated. If there are one or more acquired changes, based on the
また、上記SC2の判定の結果、変更自動推測に設定されているときは、開発者から変更推測が指示されたか否かを判定し(SC9)、変更推測が指示されたときは、変更推測部13が類似している変更を変更履歴DB14から取得し(SC10)、取得した変更が1つ以上あるか否かを判定する(SC11)。 If the result of the determination in SC2 is set to automatic change estimation, it is determined whether or not change estimation is instructed by the developer (SC9). Changes similar to 13 are acquired from the change history DB 14 (SC10), and it is determined whether there are one or more acquired changes (SC11).
この判定の結果、取得した変更がない場合は処理を終了し、取得した変更が1つ以上存在する場合は、変更推測部13が取得した変更33(複数ある場合はそれぞれの変更)に基づいて変更推測部13は影響された変更を追跡する(SC12)。
As a result of this determination, if there is no acquired change, the process is terminated. If there are one or more acquired changes, based on the
この後、変更推測部13は、追跡して得られた変更34が1つ以上存在するか否かを判定し(SC13)、存在しないときは処理を終了し、追跡して得られた変更34が1つ以上存在するときは、変更推測部13が追跡して得られた変更34のパラメータおよびターゲットを、新たに行った変更31のパラメータおよびターゲットと入れ替えて、発生する可能性がある変更32を作成し(SC14)、作成した変更32を表示部16を介して開発者に提示する(SC15)。
Thereafter, the
以上の二つの動作により、変更履歴を利用して開発者がUMLモデルを作成することを支援する。これにより、上記の方法及び装置により支援を受けずにUMLモデルを作成していた従来の場合には、UMLモデルを変更しなければならなかった部分を見落としてUMLモデルの整合性を保てなくなり、誤りや矛盾が発生したり、後にその整合性を合わせようとして手戻りが発生したが、上記の方法及び装置によって支援を受けることにより、これらの誤りや矛盾及び手戻りの発生を防ぐことができ、ソフトウェア開発者はUMLモデルを容易に短期間で作成することができるようになる。 With the above two operations, the developer is supported to create a UML model using the change history. As a result, in the conventional case where the UML model was created without assistance from the above-described method and apparatus, the UML model cannot be kept consistent by overlooking the part that had to be changed. If an error or contradiction occurs or a rework occurs in the future to try to match its consistency, the support by the above method and device can prevent the occurrence of these errors, contradictions and rework. In this way, software developers can easily create UML models in a short period of time.
従って、本実施形態によれば、複数のUML図の関係性を明確にして誤りや矛盾の発生を防ぐことができる。 Therefore, according to the present embodiment, the relationship between a plurality of UML diagrams can be clarified to prevent the occurrence of errors or contradictions.
以下、本発明の一実施例を説明する。本実施例では、図12に示すように、装置200を管理するシステム(装置管理システム)300を開発する作業を行う際に前述したUMLモデル作成支援装置10を使用する。この開発対象システム300は、データベース(DB)310を備え、「管理する装置をシステム自身に登録する」機能を持つ。
An embodiment of the present invention will be described below. In the present embodiment, as shown in FIG. 12, the UML model
装置管理システム300が内部に保持するDB310や管理する情報を設計するために、装置管理システム300の静的な構造を分析する必要がある。そのため、UMLを用いて装置管理システム300が保持するDB310のテーブルを設計するための、クラス図の1つであるテーブル設計図(図13)を作成する。
In order to design the
また、装置管理システム300が扱う情報の構造や属性を表現するための、クラス図の1つであるデータモデル図(図14)も作成する。これらのデータモデル図とテーブル設計図は両方とも装置管理システム300が扱う情報を表現しているため、共通した部分が多い。
In addition, a data model diagram (FIG. 14), which is one of the class diagrams, for expressing the structure and attributes of information handled by the
「管理する装置をシステム自身に登録する」機能を実現する動作を装置管理システム300に行わせる必要がある。そこで、UMLを用いてシーケンス図の1つである装置を登録するシーケンス図(図15)を作成し、装置管理システム300のふるまいを分析する。
It is necessary to cause the
ソフトウェア開発が終了するまでに、UMLモデルは繰り返し変更される。その変更の履歴を記録する一例を以下に示す。 By the end of software development, the UML model is repeatedly changed. An example of recording the change history is shown below.
装置の機種名を登録するというふるまいが、作成したシーケンス図(図15)には記述されていないことが開発の途中で判明したとする。図15に示すシーケンス図には、ブラウザ401と、4つのオブジェクト「JSP」402、「service」403、「DAO」404、「Entity」405、及びブラウザ401に対応する活性区間406、「service」403に対応する活性区間407、「DAO」404に対応する活性区間408、「Entity」405に対応する活性区間409が記載されている。さらに、ブラウザ401に対応する活性区間406から「service」403に対応する活性区間407への「登録する」というメッセージ410と、「service」403に対応する活性区間407から「DAO」404に対応する活性区間408への「register(name,maxRate,minRate)」というメッセージ411、および「DAO」404に対応する活性区間408から「Entity」405に対応する活性区間409へのメッセージが記載されている。
Assume that it is found during development that the behavior of registering the model name of the device is not described in the created sequence diagram (FIG. 15). The sequence diagram shown in FIG. 15 includes a
そこで、図16に示すように、装置の機種名を登録するふるまい(シーケンス図内のメッセージの更新)をシーケンス図に追加するという変更を行う。 Therefore, as shown in FIG. 16, a change is made such that the behavior for registering the model name of the apparatus (update of the message in the sequence diagram) is added to the sequence diagram.
ここで、シーケンス図に追加した「装置の機種名を登録するというふるまい」を実行するためには、装置管理システム300がその情報(機種名)を保持するテーブルを持っていなければならない。よって、図17に示すように、テーブル設計図のクラスEQUIPMENTに「EQUIPMENT_NAME」を追加する変更を行う。
Here, in order to execute the “behavior of registering the device model name” added to the sequence diagram, the
データモデル図も装置管理システム300が管理する情報を表現しているため、図18に示すように、同様に、データモデル図のクラスEquipmentにも「equipmentName」を追加する変更を行う。
Since the data model diagram also expresses information managed by the
本実施例では、開発者は上記の変更を変更履歴記録部12が記録するように選択したとする。ここで、装置200を登録するシーケンス図との整合性を保つために影響を受けて、テーブル設計図とデータモデル図の『機種名を追加する』という変更が発生したと開発者が判断し、開発者は図19に示すような依存関係を記録するように変更履歴記録部12に指示を出した。以上が、変更履歴の記録を行う一例である。
In this embodiment, it is assumed that the developer has selected the change
同様に、引数を更新する変更(equipmentName を equipmentNumber)は、図20のようになる。また、引数を削除する変更(equipmentName を削除)は、図21のようになる。 Similarly, the change for updating the argument (equipmentName is equipmentNumber) is as shown in FIG. Further, the change for deleting the argument (deletion of equipmentName) is as shown in FIG.
次に、変更履歴を利用して本発明によるUMLモデル作成支援装置10がUMLモデルの作成を支援する一例を説明する。
Next, an example in which the UML model
上記と同様に、装置200の装置IDを登録するというふるまいが、図16に示したシーケンス図には記述されていないことが判明した場合の処理について述べる。この場合、開発者は、操作部15を介して、シーケンス図に対して、図22に示すように、装置IDを登録するふるまいを追加する変更(メッセージの更新)を行う。
In the same manner as described above, processing when it is found that the behavior of registering the device ID of the
ここで開発者が操作部15を介して変更推測部13に対してこの変更を推測するように指示を出したとすると、変更推測部13は上記の『装置IDを登録するふるまいを追加する』という変更(図23)と類似した変更があるかどうか、変更履歴DB14を検索する。
Here, assuming that the developer gives an instruction to guess the change to the
変更推測部13は、図23の変更と類似している変更を変更履歴DB14から取得して、変更操作が一致するか否かを調べる。すると、図19に記録してある変更はすべて変更操作が「更新」なので一致していることになる。次に、変更推測部13は、変更対象が一致しているか否かを調べる。すると、「(シーケンス図の)メッセージ(register)」が一致していることがわかる。さらに、変更内容が一致するか否かを調べる。すると、変更内容「引数を追加する」が一致しているため、次の変更が類似していると判定でき、その変更を図24のように取得する。
The
次に、変更推測部13は、取得した変更が影響を与えている変更を変更履歴DB14から追跡する。すると、図19に記録してある「(データモデル図の)クラス(Equipment)」の変更と「(テーブル設計図の)クラス(EQUIPMENT)」の変更の二つ影響を受けていることが追跡できる。
Next, the
そこでUMLモデル作成支援装置10の変更推測部13は、『クラス(Equipment)に対して、属性「equipmentID」を追加する』と『クラス(EQUIPMENT)に対して、属性「EQUIPMENT_ID」を追加する』に相当するような変更が将来起こりうることを推測して、図25に示すように、発生する可能性がある変更を作成(パラメータに「equipmentIDに相当するもの」を代入したものを作成)し、これを表示部16を介して開発者に提示する。
Therefore, the
開発者は、ここでUMLモデル作成支援装置10から将来起こりうる変更を提示されたので、事前にその変更が起こるか確認することができる。よって、本来ならば行わなければならなかった変更を見落とし、UMLモデルの整合性が崩れてしまう可能性を防ぐことができる。
Since the developer is presented here with a change that may occur in the future from the UML model
上記のように、本実施例によれば、複数のUML図の関係性を明確にして誤りや矛盾の発生を防ぐことができる。 As described above, according to the present embodiment, the relationship between a plurality of UML diagrams can be clarified to prevent errors and contradictions from occurring.
以上が、記録した変更履歴を用いて開発者がUMLモデルを作成するのを支援する一例である。 The above is an example of assisting the developer in creating a UML model using the recorded change history.
以下に、前述した従来例と本実施形態との相違点を述べる。 Hereinafter, differences between the above-described conventional example and this embodiment will be described.
非特許文献1に記載の技術との差異:非特許文献1に記載の技術は、UML文書のメタモデルを定義し、その依存関係を自動的に生成することで開発者の作業支援を行おうとしているが、本実施形態ではメタモデルとして現れない依存関係に注目して、それを利用している点において相違する。
Difference from the technology described in Non-Patent Document 1: The technology described in
非特許文献2に記載の技術との差異:非特許文献2に記載の技術は、ソースコードの変更履歴を利用して、ソースコードの修正を支援する技術であるが、本実施形態は、ソフトウェア開発においてUMLなどのモデルが重要性を増しているという観点からUMLモデルの作成支援を行う点において相違する。 Difference from the technology described in Non-Patent Document 2: The technology described in Non-Patent Document 2 is a technology that supports the correction of the source code by using the change history of the source code. It is different in that the creation of a UML model is supported from the viewpoint that a model such as UML has increased in development.
非特許文献3に記載の技術との差異:非特許文献3に記載の技術では、版管理、構成管理ソフトウェアによって、変更の履歴を管理・追跡することができ、その履歴を利用するのはあくまで開発者自身であるが、本実施形態では、変更履歴を積極的に活用することにより、開発者の支援を行う点において相違する。 Differences from the technology described in Non-Patent Document 3: With the technology described in Non-Patent Document 3, the history of changes can be managed and tracked by version management and configuration management software. Although it is the developer himself, the present embodiment is different in that the developer is supported by actively utilizing the change history.
非特許文献4に記載の技術との差異:非特許文献4に記載の技術は、変更管理ソフトウェアによって、プロジェクトマネジメントの視点からUMLモデルの変更を管理し、変更の依頼から実行までを計画的に行い、矛盾の発生・手戻りを防いでいるが、本実施形態では、主に開発者の視点から変更間の依存関係に着目し、この依存関係を利用してUMLモデルの作成を支援する点において相違する。
Difference from the technology described in Non-Patent Document 4: The technology described in
特許文献1に記載の技術との差異:特許文献1では、その請求項8,9などで過去の成果物の変更情報を参照できる方式を提案しているが、変更情報を管理してそれを参照する方式に留まっている。しかし、本実施形態では、変更情報(変更履歴)を管理するだけではなく、変更情報を積極的に利用することによりソフトウェア開発作業を支援する点において相違する。
Difference from the technology described in Patent Document 1: In
10…UMLモデル作成支援装置、11…UMLモデル作成部、12…変更履歴記録部、13…変更推測部、14…変更履歴DB、15…操作部、16…表示部、21…変更されたUMLモデル、22…記録されていた変更、23…作成した変更、31…新たに加えられた変更、32…発生する可能性がある変更、33…類似している変更、34…影響が伝播した変更、101,111〜113,121〜125…変更、200…装置、300…開発対象システム、310…データベース(DB)、401…ブラウザ、402〜405…オブジェクト、406〜409…活性区間、410〜412…メッセージ。
DESCRIPTION OF
Claims (8)
前記コンピュータ装置は、
UMLモデルが、図と要素と関係とから構成されるものとした定義を記憶していると共に、
UMLモデルの変更とは、UMLモデルを構成する図と要素と関係のうちの少なくとも何れか1つを追加或いは削除或いは更新することであるとした定義を記憶し、
上記の定義に基づいて、作成中のUMLモデルに対して行われた変更に関する情報を変更履歴として記録する
ことを特徴とするUMLモデル作成支援方法。 A UML model creation support method for performing requirements analysis or system design using UML using a computer device,
The computer device includes:
The UML model stores definitions that are made up of diagrams, elements, and relationships,
A change in the UML model stores a definition that is to add, delete, or update at least one of a diagram, an element, and a relationship constituting the UML model,
A UML model creation support method characterized in that information on changes made to a UML model being created is recorded as a change history based on the above definition.
前記UMLモデルの変更に関する情報を新たに記録したときに、該新たな変更に影響を与えている他の変更に関する情報の記録が存在する場合、該記録として存在する他の変更が前記新たに記録した変更に対して影響を与えたという依存関係の情報を記録する
ことを特徴とする請求項1に記載のUMLモデル作成支援方法。 The computer device includes:
When information related to a change in the UML model is newly recorded, if there is a record of information related to another change affecting the new change, the other change that exists as the record is newly recorded. The UML model creation support method according to claim 1, wherein dependency information indicating that the change is influenced is recorded.
予め定義された変更の類似度に関する情報を記憶し、
作成中のUMLモデルを変更したときに、該変更と類似した他の変更を、これらの変更の類似度を判定することで前記記録されている変更履歴から検索する
ことを特徴とする請求項2に記載のUMLモデル作成支援方法。 The computer device includes:
Store information about the similarity of predefined changes,
3. When the UML model being created is changed, another change similar to the change is searched from the recorded change history by determining the similarity of these changes. The UML model creation support method described in 1.
作成中のUMLモデルに対して新たに変更が加えられようとしたときに、該変更と類似した変更を前記変更の類似度を判定することで前記記録されている変更履歴から検索すると共に、該検索によって得られた類似している変更が影響を与えた他の変更を追跡し、将来発生する可能性がある変更を作成して提示する
ことを特徴とする請求項3に記載のUMLモデル作成支援方法。 The computer device includes:
When a new change is to be added to the UML model being created, a change similar to the change is searched from the recorded change history by determining the similarity of the change, and the change 4. UML model creation according to claim 3, characterized by tracking other changes affected by similar changes obtained by searching and creating and presenting changes that may occur in the future Support method.
UMLモデルが図と要素と関係とから構成されるものとした定義と、UMLモデルの変更とはUMLモデルを構成する図と要素と関係のうちの少なくとも何れか1つを追加或いは削除或いは更新することであるとした定義を記憶する記憶手段と、
上記の定義に基づいて、作成中のUMLモデルに対して行われた変更に関する情報を変更履歴として記録する変更履歴記録手段とを備えている
ことを特徴とするUMLモデル作成支援装置。 A UML model creation support device comprising a computer device for performing requirements analysis or system design using UML,
The definition that the UML model is composed of diagrams, elements, and relationships, and the change of the UML model are the addition, deletion, or update of at least one of the diagrams, elements, and relationships that make up the UML model. Storage means for storing a definition that
A UML model creation support apparatus, comprising: a change history recording unit that records, as a change history, information relating to a change made to the UML model being created based on the above definition.
ことを特徴とする請求項5に記載のUMLモデル作成支援装置。 When the information related to the change of the UML model is newly recorded, if there is a record of information related to another change affecting the change, the change history recording means 6. The UML model creation support apparatus according to claim 5, further comprising means for recording dependency relationship information indicating that a newly recorded change has been affected.
作成中のUMLモデルを変更したときに、該変更と類似した他の変更を、これらの変更の類似度を判定することで前記変更履歴から検索する手段とを備えている
ことを特徴とする請求項6に記載のUMLモデル作成支援装置。 Means for storing information relating to the similarity of predefined changes;
When the UML model being created is changed, another change similar to the change is searched for from the change history by determining the similarity of these changes. Item 7. The UML model creation support device according to Item 6.
ことを特徴とする請求項7に記載のUMLモデル作成支援装置。 When a new change is about to be made to the UML model being created, a change similar to the change is searched from the change history by determining the similarity of the change, and the similar change The UML model creation support apparatus according to claim 7, further comprising: a unit that tracks other changes that have been influenced and creates and presents a change that may occur in the future.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005048284A JP4535906B2 (en) | 2005-02-24 | 2005-02-24 | UML model creation support method and apparatus |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005048284A JP4535906B2 (en) | 2005-02-24 | 2005-02-24 | UML model creation support method and apparatus |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2006235899A true JP2006235899A (en) | 2006-09-07 |
JP4535906B2 JP4535906B2 (en) | 2010-09-01 |
Family
ID=37043490
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005048284A Expired - Fee Related JP4535906B2 (en) | 2005-02-24 | 2005-02-24 | UML model creation support method and apparatus |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4535906B2 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008269279A (en) * | 2007-04-20 | 2008-11-06 | Meidensha Corp | Software development support system, development support method and program |
CN102426521A (en) * | 2011-10-28 | 2012-04-25 | 东南大学 | CPS (Cyber Physical Systems) adaptability verification method based on Hybrid UML (Unified Modeling Language) and theorem proving |
CN110221823A (en) * | 2019-05-31 | 2019-09-10 | 浙江大学 | A kind of business demand based on scene describes method |
JP2020042679A (en) * | 2018-09-12 | 2020-03-19 | 株式会社日立製作所 | Device and method for supporting creation of flow using visual programming tool |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH1195992A (en) * | 1997-09-17 | 1999-04-09 | Toshiba Corp | Data preparation supporting device, object-oriented analytic design supporting device and data managing method |
JP2001166924A (en) * | 1999-12-10 | 2001-06-22 | Mitsubishi Electric Corp | Device and method for managing software developed article |
-
2005
- 2005-02-24 JP JP2005048284A patent/JP4535906B2/en not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH1195992A (en) * | 1997-09-17 | 1999-04-09 | Toshiba Corp | Data preparation supporting device, object-oriented analytic design supporting device and data managing method |
JP2001166924A (en) * | 1999-12-10 | 2001-06-22 | Mitsubishi Electric Corp | Device and method for managing software developed article |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008269279A (en) * | 2007-04-20 | 2008-11-06 | Meidensha Corp | Software development support system, development support method and program |
CN102426521A (en) * | 2011-10-28 | 2012-04-25 | 东南大学 | CPS (Cyber Physical Systems) adaptability verification method based on Hybrid UML (Unified Modeling Language) and theorem proving |
CN102426521B (en) * | 2011-10-28 | 2014-04-16 | 东南大学 | CPS (Cyber Physical Systems) adaptability verification method based on Hybrid UML (Unified Modeling Language) and theorem proving |
JP2020042679A (en) * | 2018-09-12 | 2020-03-19 | 株式会社日立製作所 | Device and method for supporting creation of flow using visual programming tool |
JP7077191B2 (en) | 2018-09-12 | 2022-05-30 | 株式会社日立製作所 | Devices and methods to help you create flows with visual programming tools |
CN110221823A (en) * | 2019-05-31 | 2019-09-10 | 浙江大学 | A kind of business demand based on scene describes method |
Also Published As
Publication number | Publication date |
---|---|
JP4535906B2 (en) | 2010-09-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10546035B2 (en) | System and method for data-driven web page navigation control | |
Hallerbach et al. | Managing process variants in the process lifecycle | |
US8010946B2 (en) | Apparatus for analysing and organizing artifacts in a software application | |
US7735062B2 (en) | Software development system and method | |
US7581138B2 (en) | Method, system and computer program for managing test processes based on customized UML diagrams | |
KR101627594B1 (en) | Managing and automatically linking data objects | |
US9159039B2 (en) | Complexity reduction of user tasks | |
JP5259387B2 (en) | Method and apparatus for providing process guidance | |
US20060168577A1 (en) | Software development system and method | |
US20040216084A1 (en) | System and method of managing web content | |
US20060168555A1 (en) | Software development system and method | |
Garg et al. | An environment for managing evolving product line architectures | |
JP2007316905A (en) | Computer system and method for monitoring application program | |
Costa et al. | Version control in distributed software development: A systematic mapping study | |
KR101975272B1 (en) | System and method for recommending component reuse based on collaboration dependency | |
JP4535906B2 (en) | UML model creation support method and apparatus | |
Lohmann et al. | A model-driven approach to discovery, testing and monitoring of web services | |
EP1684170A2 (en) | Software development system and method | |
Ying et al. | Developer profiles for recommendation systems | |
JP5029118B2 (en) | Software development support system, development support method, and development support program | |
Bauer | Requirements for Dynamic Jumps at the Execution of Business Processes | |
Dam et al. | An agent-based framework for distributed collaborative model evolution | |
JP2016133946A (en) | Source code reviewing method and system therefor | |
GB2457552A (en) | Management of artifacts in collaborative software development | |
Lixandru et al. | Towards a Modeling Method for Managing Node. js Projects and Dependencies |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070125 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20091015 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100325 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100521 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100614 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100615 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130625 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140625 Year of fee payment: 4 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
LAPS | Cancellation because of no payment of annual fees |