WO2012026027A1 - ファイル管理プログラム，ファイル管理方法及びファイル管理装置 - Google Patents

ファイル管理プログラム，ファイル管理方法及びファイル管理装置 Download PDF

Info

Publication number
WO2012026027A1
WO2012026027A1 PCT/JP2010/064513 JP2010064513W WO2012026027A1 WO 2012026027 A1 WO2012026027 A1 WO 2012026027A1 JP 2010064513 W JP2010064513 W JP 2010064513W WO 2012026027 A1 WO2012026027 A1 WO 2012026027A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
charge
person
database
lending
Prior art date
Application number
PCT/JP2010/064513
Other languages
English (en)
French (fr)
Inventor
晃弘 山上
Original Assignee
富士通株式会社
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 富士通株式会社 filed Critical 富士通株式会社
Priority to JP2012530490A priority Critical patent/JPWO2012026027A1/ja
Priority to PCT/JP2010/064513 priority patent/WO2012026027A1/ja
Publication of WO2012026027A1 publication Critical patent/WO2012026027A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots

Definitions

  • the present invention relates to a technique for managing files.
  • an object of the present invention is to provide a file management technique in which approval processing and version management are linked.
  • the computer includes a storage storing the first database and the second database.
  • the first database for each file constituting the original, at least one version number and a storage destination are associated with the file name and registered.
  • the second database a person in charge of work and at least one file to be worked are registered in association with each other.
  • the computer lends the file to the person in charge when the person in charge of the loan request is registered in the second database when the file is requested to be rented.
  • the computer when the file is returned, if the person responsible for the return and the file are registered in the second database, the computer newly saves the file in the storage, and the file name of the first database Add and register the version number and save destination. Furthermore, when the returned file is approved, the computer merges the approved file with the original.
  • FIG. 1 shows an example of an information system in the present embodiment.
  • a file management apparatus 100 constructed using a computer is connected to at least one client computer 300 operated by an administrator and a person in charge via a network 200 such as a LAN (Local Area Network) or a WAN (Wide Area Network). Connected.
  • a network 200 such as a LAN (Local Area Network) or a WAN (Wide Area Network). Connected.
  • the file management apparatus 100 has a storage 110 for storing a version management DB (Database) 110A, a task management DB 110B, a configuration management DB 110C, and a lending management DB 110D.
  • a storage 110 for example, an external storage device such as HD (Hard Disk) or SSD (Solid State Drive) can be used.
  • HD Hard Disk
  • SSD Solid State Drive
  • the version management DB 110A and the task management DB 110B are examples of the first database and the second database, respectively.
  • the version number management DB 110A is a set of records for managing each file for each version number (version) of the original application program including various files such as source code and documents. As shown in FIG. 2, the version number management DB 110A holds a record in which a file name as an example of a file identifier, a version number, and a file storage location (save destination) are associated with each other.
  • a file name as an example of a file identifier
  • a version number a version number
  • file storage location can be associated with one file name.
  • the file storage location is expressed by a file name with an absolute path.
  • the task management DB 110B is a collection of records for managing tasks (work) such as function addition to the original.
  • the task management DB 110B includes a task ID (identifier) for identifying a task, work contents, a person in charge of the work, file information for identifying a file to be worked, A record in which the state indicating the progress of the task is associated is retained.
  • a file name to which the character string indicating the version number is not attached as the file information, considering that the same file may be lent to a plurality of persons in charge.
  • a plurality of file information can be associated with one task ID.
  • the configuration management DB 110C is a collection of records for managing the configuration (combination) of the original file (original file) and the file (rental file) lent as a work target. As shown in FIG. 4, the configuration management DB 110C includes a branch name for identifying a branch used in configuration management, a lock state indicating whether the contents can be changed, and a file to be managed in the branch. A record in which the information is associated with the version number of the file is retained.
  • a branch is one of the important concepts in configuration management, and refers to a mechanism for separating development environments in order to achieve different purposes such as function addition and bug correction. Further, at least one file information and version number are associated with one branch.
  • the lending management DB 110D is a collection of records for associating the task management DB 110B and the configuration management DB 110C for the purpose of managing lending files.
  • the lending management DB 110D has a lending ID for specifying a lending unit for a file, a branch name used for lending a file, a task ID, a state indicating a lending state of the file, Keep the record associated with.
  • the branch name is set to the branch name of the configuration management DB 110C shown in FIG. 4, while the task ID is set to the task ID of the task management DB 110B shown in FIG.
  • the file management apparatus 100 embodies a task creation unit 120, a file lending unit 130, a file return unit 140, and an approval unit 150 by executing a file management program.
  • the file management program is installed in the storage 110 from a computer-readable recording medium such as a CD-ROM (Compact Disk Read Only Memory) or a DVD-ROM (Digital Versatile Disk Disk Read Only Memory) using a known method. Is done.
  • the task creation unit 120 registers an additional task in the task management DB 110B of the storage 110 and receives a task in the client computer 300 operated by the person in charge when a task creation instruction is issued from the client computer 300 operated by the administrator. To be notified.
  • the file lending unit 130 lends a file using a lending branch used for lending a file when a file lending request is received from the client computer 300 operated by the person in charge.
  • the file return unit 140 stores the returned file (return file) when the file is returned from the client computer 300 operated by the person in charge.
  • the approval unit 150 displays a screen for approving or denying the return file in response to an approval instruction from the client computer 300 operated by the administrator, and the original return file that has been approved by the administrator To merge.
  • FIG. 6 shows an example of task creation processing executed by the task creation unit 120 when a task creation instruction is received from the client computer 300.
  • step 1 the task creation unit 120 displays a task creation screen for creating a task in an interactive format, for example, on the client computer 300 that issued the task creation instruction. Display.
  • the work content, the person in charge, and the file information are input on the task creation screen.
  • step 2 the task creation unit 120 updates the task management DB 110B of the storage 110. That is, the task creation unit 120 automatically assigns a task ID according to a predetermined rule, and the task ID, the work content, the person in charge and the file information input on the task creation screen, and the status “rental request” Create a record that associates "wait”. Then, the task creation unit 120 additionally registers a record in the task management DB 110B.
  • step 3 the task creation unit 120 creates a task including at least work contents, and notifies the person in charge of the task via e-mail, for example.
  • the task management DB 110B is updated and the task is notified to the person in charge. For this reason, the file management apparatus 100 is ready to lend a file, while the person in charge is ready to change a file according to a task.
  • FIG. 7 shows an example of a file lending process executed by the file lending unit 130 when a file lending request is received from the client computer 300.
  • the file lending unit 130 refers to the task management DB 110 ⁇ / b> B of the storage 110 and determines whether or not the lending request is suitable for the task. That is, the file lending unit 130 determines whether or not the lending request conforms to the task through whether or not the record including the person in charge related to the lending request is registered in the task management DB 110B. If the file lending unit 130 determines that the lending request is suitable for the task, the process advances to step 12 (Yes), whereas if it is determined that the lending request is not suitable for the task, the process advances to step 19. (No).
  • step 12 the file lending unit 130 determines whether or not to create a lending branch, for example, in accordance with the content instructed in advance by the administrator.
  • the file lending unit 130 proceeds to step 13 if it is determined to create a lending branch (Yes), and proceeds to step 16 if it is determined not to create a lending branch (No).
  • step 13 the file lending unit 130 creates a lending branch with a name that functions as an identifier.
  • step 14 the file lending unit 130 updates the configuration management DB 110 ⁇ / b> C of the storage 110. That is, the file lending unit 130 creates a record that associates the lending branch name, “changeable” as the lock state, file information related to the lending request, and the version number of the file.
  • the file lending unit 130 additionally registers a record in the configuration management DB 110C.
  • the version number of the file may be the succession of the version number of the original file from which the rental file is derived.
  • step 15 the file lending unit 130 updates the lending management DB 110D of the storage 110. That is, the file lending unit 130 automatically assigns a lending ID according to a predetermined rule, the lending ID, the branch name of the lending branch created in step 13, the task ID related to the lending request, and the state Create a record associating “Lending”.
  • the file lending unit 130 additionally registers a record in the lending management DB 110D.
  • step 16 the file lending unit 130 refers to the configuration management DB 110C of the storage 110, and confirms the lock state of the lending branch used for lending the file. Then, the file lending unit 130 proceeds to step 17 if the lock state is “changeable”, and ends the process if the lock state is “unchangeable”.
  • step 17 the file lending unit 130 updates the task management DB 110B of the storage 110. That is, the file lending unit 130 rewrites the state of the record specified by the task ID related to the lending request to “lending”.
  • the file lending unit 130 lends the file by notifying the client computer 300 that issued the lending request of the lending branch name and the task ID indicating what to do there. That is, the file lending unit 130 refers to the task management DB 110B and acquires the task ID. Further, the file lending unit 130 refers to the lending management DB 110D and acquires the lending branch name from the record including the task ID. Then, the file lending unit 130 notifies the task ID and the lending branch name.
  • the file lending unit 130 notifies the client computer 300 that the lending request is invalid.
  • the file lending process when a file lending request is received from the client computer 300, it is determined whether or not the lending request conforms to the task. If the lending request matches the task, the lending branch name and task ID are notified to the client computer 300. For this reason, the person in charge of the task can refer to the task management DB 110B, read the file specified by the file information associated with the task ID into the client computer 300, and change the rental file according to the task. Further, when the lending branch is locked, the file is not lent in response to the lending request, so that file management can be ensured. Further, when an existing lending branch is available, a plurality of tasks are assigned to one lending branch. In this case, a plurality of tasks are managed by one lending branch. For example, file changes by a plurality of persons in charge can be merged into the original at once.
  • FIG. 8 shows an example of a file return process executed by the file return unit 140 when a file is returned from the client computer 300 to the lending branch.
  • the file return unit 140 refers to the configuration management DB 110 ⁇ / b> C of the storage 110 and confirms the lock state of the lending branch used for returning the file. Then, the file return unit 140 advances the process to step 22 if the lock state is “changeable”, and ends the process if the lock state is “changeable”.
  • the file return unit 140 refers to the task management DB 110B of the storage 110 and determines whether or not the return is suitable for the task. That is, the file return unit 140 determines whether or not the return is suitable for the task through whether or not the person in charge of the return file and the record including the file information are registered in the task management DB 110B. If the file return unit 140 determines that the return is suitable for the task, the process proceeds to step 23 (Yes), whereas if it is determined that the return is not suitable for the task, the process proceeds to step 28 (No). ).
  • step 23 the file return unit 140 newly saves the return file in the storage 110.
  • a unique file name in which an arbitrary character string (version number or the like) is added to the file information is used.
  • step 24 the file return unit 140 updates the version number management DB 110A of the storage 110. That is, the file return unit 140 refers to the version management DB 110A and additionally registers the updated version number and file storage location for the record related to the return file.
  • step 25 the file return unit 140 updates the lending management DB 110D of the storage 110. That is, the file return unit 140 rewrites the status to “returned” for a predetermined record in the lending management DB 110D.
  • step 26 the file return unit 140 updates the task management DB 110B of the storage 110. That is, the file return unit 140 rewrites the state of the predetermined record in the task management DB 110B to “returned”.
  • step 27 the file return unit 140 notifies the client computer 300 operated by the administrator that the file has been returned.
  • step 28 the file return unit 140 notifies the client computer 300 that the file return is invalid.
  • this file return process when a file is returned from the client computer 300 to the lending branch, it is determined whether or not the return is suitable for the task. If the return matches the task, the file is newly saved in the storage 110 and the version number of the file is updated. At this time, since the file is stored so as not to be overwritten on the file stored in the storage 110, a plurality of version numbers coexist for the same file, and a file of an arbitrary version number can be referred to. Further, since the return of the file is not accepted when the lending branch is locked, it is possible to prevent an unexpected file from being saved.
  • FIG. 9 shows an example of an approval process executed by the approval unit 150 when an approval instruction is issued from the client computer 300.
  • the approval unit 150 causes the client computer 300 that issued the approval instruction to display an approval screen for approving or denying the return file in an interactive format, for example.
  • step 32 the approval unit 150 determines whether the return file has been approved through the approval screen. If the approval unit 150 determines that the return file has been approved, the process proceeds to step 33 (Yes), whereas if it determines that the return file is not approved (that is, denied), the process proceeds to step 37. Advance (No).
  • step 33 the approval unit 150 updates the configuration management DB 110C of the storage 110. That is, the approval unit 150 rewrites the lock state of the record related to the return file to “unchangeable”.
  • step 34 the approval unit 150 merges the return file with the original.
  • step 35 the approval unit 150 updates the task management DB 110B of the storage 110. That is, the approval unit 150 rewrites the state of the record related to the return file to “completed”.
  • step 36 the approval unit 150 updates the lending management DB 110D of the storage 110.
  • the approval unit 150 rewrites the state of the record related to the return file to “original reflected”.
  • step 37 the approval unit 150 notifies the client computer 300 related to the return file that the approval cannot be made via e-mail, for example. Note that this notification may include the reason for the rejection input by the administrator.
  • the return file is merged with the original, and the task management DB 110B, the configuration management DB 110C, and the lending management DB 110D are updated. Is done. For this reason, unless the return file is approved, the return file is not merged with the original, and for example, it is possible to prevent a return file in which the work content of the task is incomplete from being merged with the original.
  • the file approval process and the version number management are performed in cooperation with each other. For example, it is possible to prevent different files having the same file name from being reflected in the original. .
  • the task creation unit 120 When there is a task creation instruction from the client computer 300 operated by the administrator (procedure 1), the task creation unit 120 additionally registers a new task in the task management DB 110B (procedure 2). The task creation unit 120 notifies the task to the client computer 300 operated by the person in charge of processing the task (procedure 3).
  • the approval unit 150 updates the configuration management DB 110C (procedure 14) and merges the return file with the original (procedure 15). Further, the approval unit 150 updates the task management DB 110B and the lending management DB 110D (procedure 16).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　コンピュータを用いて構築されたファイル管理装置は、タスクに則って作業対象となる少なくとも１つのファイルを貸し出す。また、ファイル管理装置は、タスクに適合したファイルが返却されたときに、返却ファイルをストレージに新規保存する一方、返却ファイルの承認が行われたときに、承認を経たファイルを原本にマージする。そして、承認処理と版数管理とを連携させることで、例えば、ファイル名が同一の異なるファイルが原本にマージされてしまうことを防止する。

Description

ファイル管理プログラム，ファイル管理方法及びファイル管理装置
　本発明は、ファイルを管理する技術に関する。
　プログラムのソースコード，ドキュメントなどの各種ファイルは、例えば、機能拡張，バグフィックスなどに応じて逐次変更される。このため、原本から派生させたファイルを貸し出すと共に、内容が変更されたファイルが返却されたときに、電子会議システムで変更を承認したファイルのみを原本にマージ（反映）させることで、ファイルの管理を容易にした技術が提案されている。
特開２００７－２１９８２９号公報
　ところで、ファイルの管理においては、ファイルの貸出から原本へのマージまでを管理するだけでは足りず、返却されたファイルが貸し出したファイルを変更したものであるかを管理する版数管理も併せて行うべきである。しかしながら、従来提案技術においては、承認を経たファイルのみが版数管理の対象となっていたため、承認処理と版数管理とが連携しておらず、例えば、ファイル名が同一の承認したファイルとは異なるファイルが原本にマージされてしまうおそれがあった。
　そこで、本発明は従来技術の問題点に鑑み、承認処理と版数管理とを連携させたファイル管理技術を提供することを目的とする。
　コンピュータは、第１のデータベース及び第２のデータベースを格納したストレージを備える。第１のデータベースには、原本を構成する各ファイルについて、ファイル名に対して少なくとも１つの版数及び保存先が関連付けて登録される。第２のデータベースには、作業の担当者及び作業対象となる少なくとも１つのファイルが関連付けて登録される。
　そして、コンピュータは、ファイルの貸出依頼があったときに、貸出依頼に係る担当者が第２のデータベースに登録されていれば、担当者にファイルを貸し出す。また、コンピュータは、ファイルの返却があったときに、返却に係る担当者及びファイルが第２のデータベースに登録されていれば、ファイルをストレージに新規保存すると共に、第１のデータベースについて、ファイル名に対して版数及び保存先を追加登録する。さらに、コンピュータは、返却されたファイルの承認が行われたときに、承認を経たファイルを原本にマージする。
　ファイルの承認処理と版数管理とが連携して行われるため、例えば、ファイル名が同一の承認したファイルとは異なるファイルが原本にマージされてしまうことを防止できる。
実施形態における情報システムの一例を示す構成図である。 版数管理ＤＢのデータ構造図である。 タスク管理ＤＢのデータ構造図である。 構成管理ＤＢのデータ構造図である。 貸出管理ＤＢのデータ構造図である。 タスク作成処理の一例を説明するためのフローチャートである。 ファイル貸出処理の一例を説明するためのフローチャートである。 ファイル返却処理の一例を説明するためのフローチャートである。 承認処理の一例を説明するためのフローチャートである。 タスク作成から承認までの処理流れの説明図である。
　以下、添付された図面を参照し、本発明を実施するための実施形態について詳細に説明する。
　図１は、本実施形態における情報システムの一例を示す。
　コンピュータを用いて構築されたファイル管理装置１００は、ＬＡＮ（Local Area Network），ＷＡＮ（Wide Area Network）などのネットワーク２００を介して、管理者及び担当者が操作する少なくとも１台のクライアントコンピュータ３００に接続される。
　ファイル管理装置１００は、版数管理ＤＢ（Database）１１０Ａ，タスク管理ＤＢ１１０Ｂ，構成管理ＤＢ１１０Ｃ及び貸出管理ＤＢ１１０Ｄを格納するためのストレージ１１０を有する。ここで、ストレージ１１０としては、例えば、ＨＤ（Hard Disk），ＳＳＤ（Solid State Drive）などの外部記憶装置が利用できる。なお、版数管理ＤＢ１１０Ａ及びタスク管理ＤＢ１１０Ｂは、夫々、第１のデータベース及び第２のデータベースの一例として挙げられる。
　版数管理ＤＢ１１０Ａは、例えば、ソースコード及びドキュメントなどの各種ファイルからなるアプリケーションプログラムの原本について、各ファイルを版数（バージョン）ごとに管理するためのレコードの集合体である。版数管理ＤＢ１１０Ａは、図２に示すように、ファイル識別子の一例としてのファイル名と、版数と、ファイル格納場所（保存先）と、を関連付けたレコードを保持する。ここで、１つのファイルについて複数の版数が並存し得ることに鑑み、１つのファイル名に対して複数の版数及びファイル格納場所を関連付けられるようにする。また、ファイル格納場所は、絶対パスを付したファイル名で表現する。
　タスク管理ＤＢ１１０Ｂは、原本に対する機能追加などのタスク（作業）を管理するためのレコードの集合体である。タスク管理ＤＢ１１０Ｂは、図３に示すように、タスクを特定するためのタスクＩＤ（identifier）と、作業内容と、作業を担う担当者と、作業対象となるファイルを特定するためのファイル情報と、タスクの進捗状況を示す状態と、を関連付けたレコードを保持する。ここで、ファイル情報は、同一ファイルを複数の担当者に貸し出す場合があることを踏まえ、例えば、版数を示す文字列が付されないファイル名を用いることが望ましい。また、１つのタスクについて複数のファイルが作業対象となり得ることに鑑み、１つのタスクＩＤに対して複数のファイル情報を関連付けられるようにする。
　構成管理ＤＢ１１０Ｃは、原本となるファイル（原本ファイル）、及び、作業対象として貸し出されるファイル（貸出ファイル）の構成（組み合わせ）を管理するためのレコードの集合体である。構成管理ＤＢ１１０Ｃは、図４に示すように、構成管理で使用されるブランチを特定するためのブランチ名と、内容が変更可能であるか否かを示すロック状態と、ブランチにおいて管理対象となるファイル情報と、ファイルの版数と、を関連付けたレコードを保持する。ここで、ブランチとは、構成管理上の重要な概念の１つであって、例えば、機能追加やバグ修正など、異なる目的を達成するために開発環境を分離する仕組みのことをいう。また、ファイル情報及び版数は、１つのブランチに対して少なくとも１つ関連付けられる。
　貸出管理ＤＢ１１０Ｄは、貸出ファイルを管理することを目的として、タスク管理ＤＢ１１０Ｂ及び構成管理ＤＢ１１０Ｃを関連付けるためのレコードの集合体である。貸出管理ＤＢ１１０Ｄは、図５に示すように、ファイルの貸出単位を特定するための貸出ＩＤと、ファイルの貸出に使用するためのブランチ名と、タスクＩＤと、ファイルの貸出状態を示す状態と、を関連付けたレコードを保持する。ここで、ブランチ名には、図４に示す構成管理ＤＢ１１０Ｃのブランチ名が設定される一方、タスクＩＤには、図３に示すタスク管理ＤＢ１１０ＢのタスクＩＤが設定される。
　ファイル管理装置１００は、ファイル管理プログラムを実行することで、図１に示すように、タスク作成部１２０，ファイル貸出部１３０，ファイル返却部１４０及び承認部１５０を夫々具現化する。ファイル管理プログラムは、例えば、ＣＤ－ＲＯＭ（Compact Disk Read Only Memory），ＤＶＤ－ＲＯＭ（Digital Versatile Disk Read Only Memory）などのコンピュータ読取可能な記録媒体から、公知の手段を用いて、ストレージ１１０にインストールされる。
　タスク作成部１２０は、管理者が操作するクライアントコンピュータ３００からタスク作成指示があったことを契機として、ストレージ１１０のタスク管理ＤＢ１１０Ｂにタスクを追加登録すると共に、担当者が操作するクライアントコンピュータ３００にタスクを通知する。ファイル貸出部１３０は、担当者が操作するクライアントコンピュータ３００からファイルの貸出依頼があったことを契機として、ファイルの貸出に利用する貸出ブランチを使用してファイルの貸出を行う。ファイル返却部１４０は、担当者が操作するクライアントコンピュータ３００からファイルの返却があったことを契機として、返却されたファイル（返却ファイル）を保存する。承認部１５０は、管理者が操作するクライアントコンピュータ３００から承認指示があったことを契機として、返却ファイルの承認又は否認を行うための画面を表示すると共に、管理者の承認を経た返却ファイルを原本にマージする。
　次に、ファイル管理装置１００のタスク作成部１２０，ファイル貸出部１３０，ファイル返却部１４０及び承認部１５０が夫々実行する処理について説明する。
　図６は、クライアントコンピュータ３００からタスク作成指示があったことを契機として、タスク作成部１２０が実行するタスク作成処理の一例を示す。
　ステップ１（図では「Ｓ１」と略記する。以下同様。）では、タスク作成部１２０が、タスク作成指示を発行したクライアントコンピュータ３００に、例えば、対話形式でタスクを作成するためのタスク作成画面を表示させる。ここで、タスク作成画面では、少なくとも、作業内容，担当者及びファイル情報を入力させる。
　ステップ２では、タスク作成部１２０が、ストレージ１１０のタスク管理ＤＢ１１０Ｂを更新する。即ち、タスク作成部１２０は、所定ルールに則ってタスクＩＤを自動的に採番し、タスクＩＤと、タスク作成画面で入力された作業内容，担当者及びファイル情報と、状態としての「貸出依頼待ち」と、を関連付けたレコードを作成する。そして、タスク作成部１２０は、タスク管理ＤＢ１１０Ｂにレコードを追加登録する。
　ステップ３では、タスク作成部１２０が、少なくとも作業内容を含んだタスクを作成し、例えば、電子メールを介して、担当者にタスクを通知する。
　かかるタスク作成処理によれば、管理者によるクライアントコンピュータ３００の操作に応じてタスクが作成されると、タスク管理ＤＢ１１０Ｂが更新されると共に、担当者にタスクが通知される。このため、ファイル管理装置１００においては、ファイルを貸し出す準備が完了する一方、担当者においては、タスクに従ってファイルを変更する準備が完了する。
　図７は、クライアントコンピュータ３００からファイルの貸出依頼があったことを契機として、ファイル貸出部１３０が実行するファイル貸出処理の一例を示す。
　ステップ１１では、ファイル貸出部１３０が、ストレージ１１０のタスク管理ＤＢ１１０Ｂを参照し、タスクに適合した貸出依頼であるか否かを判定する。即ち、ファイル貸出部１３０は、貸出依頼に係る担当者を含むレコードがタスク管理ＤＢ１１０Ｂに登録されているか否かを介して、タスクに適合した貸出依頼であるか否かを判定する。そして、ファイル貸出部１３０は、タスクに適合した貸出依頼であると判定すれば処理をステップ１２へと進める一方（Ｙｅｓ）、タスクに適合した貸出依頼でないと判定すれば処理をステップ１９へと進める（Ｎｏ）。
　ステップ１２では、ファイル貸出部１３０が、例えば、管理者が予め指示した内容に応じて、貸出ブランチを作成するか否かを判定する。そして、ファイル貸出部１３０は、貸出ブランチを作成すると判定すれば処理をステップ１３へと進める一方（Ｙｅｓ）、貸出ブランチを作成しないと判定すれば処理をステップ１６へと進める（Ｎｏ）。
　ステップ１３では、ファイル貸出部１３０が、識別子として機能する名称を付した貸出ブランチを作成する。
　ステップ１４では、ファイル貸出部１３０が、ストレージ１１０の構成管理ＤＢ１１０Ｃを更新する。即ち、ファイル貸出部１３０は、貸出ブランチ名と、ロック状態としての「変更可」と、貸出依頼に係るファイル情報と、ファイルの版数と、を関連付けたレコードを作成する。そして、ファイル貸出部１３０は、構成管理ＤＢ１１０Ｃにレコードを追加登録する。ここで、ファイルの版数は、例えば、貸出ファイルの派生元である原本ファイルの版数を承継すればよい。
　ステップ１５では、ファイル貸出部１３０が、ストレージ１１０の貸出管理ＤＢ１１０Ｄを更新する。即ち、ファイル貸出部１３０は、所定ルールに則って貸出ＩＤを自動的に採番し、貸出ＩＤと、ステップ１３で作成した貸出ブランチのブランチ名と、貸出依頼に係るタスクＩＤと、状態としての「貸出中」と、を関連付けたレコードを作成する。そして、ファイル貸出部１３０は、貸出管理ＤＢ１１０Ｄにレコードを追加登録する。
　ステップ１６では、ファイル貸出部１３０が、ストレージ１１０の構成管理ＤＢ１１０Ｃを参照し、ファイルの貸出に利用する貸出ブランチのロック状態を確認する。そして、ファイル貸出部１３０は、ロック状態が「変更可」であれば処理をステップ１７へと進める一方、ロック状態が「変更不可」であれば処理を終了させる。
　ステップ１７では、ファイル貸出部１３０が、ストレージ１１０のタスク管理ＤＢ１１０Ｂを更新する。即ち、ファイル貸出部１３０は、貸出依頼に係るタスクＩＤにより特定されるレコードの状態を「貸出中」に書き換える。
　ステップ１８では、ファイル貸出部１３０が、貸出依頼を発行したクライアントコンピュータ３００に、貸出ブランチ名とそこで何をすべきかを示したタスクＩＤとを通知することで、ファイルを貸し出す。即ち、ファイル貸出部１３０は、タスク管理ＤＢ１１０Ｂを参照し、タスクＩＤを取得する。また、ファイル貸出部１３０は、貸出管理ＤＢ１１０Ｄを参照し、タスクＩＤを含むレコードから貸出ブランチ名を取得する。そして、ファイル貸出部１３０は、タスクＩＤ及び貸出ブランチ名を通知する。
　ステップ１９では、ファイル貸出部１３０が、クライアントコンピュータ３００に対して、貸出依頼が不当であることを通知する。
　かかるファイル貸出処理によれば、クライアントコンピュータ３００からファイルの貸出依頼があると、タスクに適合した貸出依頼であるか否かが判定される。そして、貸出依頼がタスクに適合していれば、クライアントコンピュータ３００に貸出ブランチ名及びタスクＩＤが通知される。このため、タスクを処理する担当者は、タスク管理ＤＢ１１０Ｂを参照し、タスクＩＤに関連付けられたファイル情報により特定されるファイルをクライアントコンピュータ３００に読み込み、タスクに従って貸出ファイルを変更することができる。また、貸出ブランチがロックされているときには、貸出依頼に応答してファイルが貸し出されないため、ファイル管理を確実ならしめることができる。さらに、既存の貸出ブランチが利用可能であるときには、１つの貸出ブランチに複数のタスクが割り付けられる。この場合、１つの貸出ブランチで複数のタスクが管理されることとなり、例えば、複数の担当者によるファイルの変更を一括して原本にマージすることができる。
　図８は、クライアントコンピュータ３００から貸出ブランチにファイルが返却されたことを契機として、ファイル返却部１４０が実行するファイル返却処理の一例を示す。
　ステップ２１では、ファイル返却部１４０が、ストレージ１１０の構成管理ＤＢ１１０Ｃを参照し、ファイルの返却に利用する貸出ブランチのロック状態を確認する。そして、ファイル返却部１４０は、ロック状態が「変更可」であれば処理をステップ２２へと進める一方、ロック状態が「変更不可」であれば処理を終了させる。
　ステップ２２では、ファイル返却部１４０が、ストレージ１１０のタスク管理ＤＢ１１０Ｂを参照し、タスクに適合した返却であるか否かを判定する。即ち、ファイル返却部１４０は、返却ファイルに係る担当者及びファイル情報を含むレコードがタスク管理ＤＢ１１０Ｂに登録されているか否かを介して、タスクに適合した返却であるか否かを判定する。そして、ファイル返却部１４０は、タスクに適合した返却であると判定すれば処理をステップ２３へと進める一方（Ｙｅｓ）、タスクに適合した返却でないと判定すれば処理をステップ２８へと進める（Ｎｏ）。
　ステップ２３では、ファイル返却部１４０が、返却ファイルをストレージ１１０に新規保存する。このとき、ストレージ１１０に保存されているファイルが上書きされないようにすべく、例えば、ファイル情報に対して任意の文字列（版数など）を付加したユニークなファイル名とする。
　ステップ２４では、ファイル返却部１４０が、ストレージ１１０の版数管理ＤＢ１１０Ａを更新する。即ち、ファイル返却部１４０は、版数管理ＤＢ１１０Ａを参照し、返却ファイルに係るレコードについて、更新された版数及びファイル格納場所を追加登録する。
　ステップ２５では、ファイル返却部１４０が、ストレージ１１０の貸出管理ＤＢ１１０Ｄを更新する。即ち、ファイル返却部１４０は、貸出管理ＤＢ１１０Ｄの所定レコードについて、状態を「返却済み」に書き換える。
　ステップ２６では、ファイル返却部１４０が、ストレージ１１０のタスク管理ＤＢ１１０Ｂを更新する。即ち、ファイル返却部１４０は、タスク管理ＤＢ１１０Ｂの所定レコードについて、状態を「返却済み」に書き換える。
　ステップ２７では、ファイル返却部１４０が、管理者が操作するクライアントコンピュータ３００に対して、ファイルが返却されたことを通知する。
　ステップ２８では、ファイル返却部１４０が、クライアントコンピュータ３００に対して、ファイル返却が不当であることを通知する。
　かかるファイル返却処理によれば、クライアントコンピュータ３００から貸出ブランチにファイルが返却されると、タスクに適合した返却であるか否かが判定される。そして、返却がタスクに適合していれば、ストレージ１１０にファイルが新規保存されると共に、ファイルの版数が更新される。このとき、ファイルは、ストレージ１１０に保存されているファイルに上書きされないように保存されるため、同一のファイルについて複数の版数が並存し、任意の版数のファイルを参照できるようになる。また、貸出ブランチがロックされているときには、ファイルの返却を受け付けないため、想定外のファイルが保存されることを防止できる。
　図９は、クライアントコンピュータ３００から承認指示があったことを契機として、承認部１５０が実行する承認処理の一例を示す。
　ステップ３１では、承認部１５０が、承認指示を発行したクライアントコンピュータ３００に、例えば、対話形式で返却ファイルの承認又は否認を行なうための承認画面を表示させる。
　ステップ３２では、承認部１５０が、承認画面を通して返却ファイルが承認されたか否かを判定する。そして、承認部１５０は、返却ファイルが承認されたと判定すれば処理をステップ３３へと進める一方（Ｙｅｓ）、返却ファイルが承認されない（即ち、否認された）と判定すれば処理をステップ３７へと進める（Ｎｏ）。
　ステップ３３では、承認部１５０が、ストレージ１１０の構成管理ＤＢ１１０Ｃを更新する。即ち、承認部１５０は、返却ファイルに係るレコードのロック状態を「変更不可」に書き換える。
　ステップ３４では、承認部１５０が、原本に対して返却ファイルをマージする。
　ステップ３５では、承認部１５０が、ストレージ１１０のタスク管理ＤＢ１１０Ｂを更新する。即ち、承認部１５０は、返却ファイルに係るレコードの状態を「完了」に書き換える。
　ステップ３６では、承認部１５０が、ストレージ１１０の貸出管理ＤＢ１１０Ｄを更新する。即ち、承認部１５０は、返却ファイルに係るレコードの状態を「原本反映済み」に書き換える。
　ステップ３７では、承認部１５０が、返却ファイルに係るクライアントコンピュータ３００に対して、例えば、電子メールを介して、承認できないことを通知する。なお、この通知には、管理者によって入力された否認理由を含めるようにしてもよい。
　かかる承認処理によれば、管理者によるクライアントコンピュータ３００の操作に応じて返却ファイルの承認が行われると、原本に返却ファイルがマージされると共に、タスク管理ＤＢ１１０Ｂ，構成管理ＤＢ１１０Ｃ及び貸出管理ＤＢ１１０Ｄが更新される。このため、返却ファイルの承認が行われない限り、原本に返却ファイルがマージされることがなく、例えば、タスクの作業内容が未完である返却ファイルが原本にマージされることを防止できる。
　従って、以上説明したファイル管理装置１００によれば、ファイルの承認処理と版数管理とが連携して行われるため、例えば、ファイル名が同一の異なるファイルが原本に反映されてしまうことを防止できる。
　ここで、ファイル管理装置１００について理解を容易ならしめることを目的とし、図１０を参照して、タスク作成から承認までの処理流れについて説明する。
　［タスク作成］
　管理者が操作するクライアントコンピュータ３００からタスク作成指示があると（手順１）、タスク作成部１２０は、新たなタスクをタスク管理ＤＢ１１０Ｂに追加登録する（手順２）。また、タスク作成部１２０は、タスクを処理する担当者が操作するクライアントコンピュータ３００にタスクを通知する（手順３）。
　［ファイル貸出］
　担当者が操作するクライアントコンピュータ３００からファイルの貸出依頼があると（手順４）、ファイル貸出部１３０は、必要に応じて、貸出ブランチを作成すると共に（手順５）、構成管理ＤＢ１１０Ｃ及び貸出管理ＤＢ１１０Ｄを更新する（手順６）。また、ファイル貸出部１３０は、タスク管理ＤＢ１１０Ｂを更新すると共に（手順７）、担当者が操作するクライアントコンピュータ３００にファイルを貸し出す（手順８）。
　［ファイル返却］
　担当者が操作するクライアントコンピュータ３００からファイルが返却されると（手順９）、ファイル返却部１４０は、返却ファイルをストレージ１１０に新規保存すると共に（手順１０）、版数管理ＤＢ１１０Ａを更新する（手順１１）。また、ファイル返却部１４０は、タスク管理ＤＢ１１０Ｂ及び貸出管理ＤＢ１１０Ｄを更新する（手順１２）。
　［承認］
　管理者が操作するクライアントコンピュータ３００から承認指示があると（手順１３）、承認部１５０は、構成管理ＤＢ１１０Ｃを更新すると共に（手順１４）、返却ファイルを原本にマージする（手順１５）。また、承認部１５０は、タスク管理ＤＢ１１０Ｂ及び貸出管理ＤＢ１１０Ｄを更新する（手順１６）。
　　１００　　ファイル管理装置（コンピュータ）
　　１１０　　ストレージ
　　１１０Ａ　版数管理ＤＢ
　　１１０Ｂ　タスク管理ＤＢ
　　１２０　　タスク作成部
　　１３０　　ファイル貸出部
　　１４０　　ファイル返却部
　　１５０　　承認部

Claims (8)

  1. 　原本を構成する各ファイルについて、ファイル名に対して少なくとも１つの版数及び保存先を関連付けて登録する第１のデータベースと、作業の担当者及び作業対象となる少なくとも１つのファイルを関連付けて登録する第２のデータベースと、を格納したストレージを有するコンピュータに、
    　ファイルの貸出依頼があったときに、前記貸出依頼に係る担当者が前記第２のデータベースに登録されているか否かを判定し、前記担当者が前記第２のデータベースに登録されていれば、前記担当者にファイルを貸し出すステップと、
    　ファイルの返却があったときに、前記返却に係る担当者及びファイルが前記第２のデータベースに登録されているか否かを判定し、前記担当者及びファイルが前記第２のデータベースに登録されていれば、前記ファイルを前記ストレージに新規保存すると共に、前記第１のデータベースについて、返却されたファイルのファイル名に対して版数及び保存先を追加登録するステップと、
    　返却されたファイルの承認が行われたとき、前記承認を経たファイルを前記原本にマージするステップと、
    　を実現させるためのファイル管理プログラム。
  2. 　前記ファイルの貸出及び返却は、構成管理で使用されるブランチにおいて行われることを特徴とする請求項１記載のファイル管理プログラム。
  3. 　前記ブランチには、前記作業の担当者及び作業対象となる少なくとも１つのファイルが複数割付可能であることを特徴とする請求項２記載のファイル管理プログラム。
  4. 　前記コンピュータに、前記ファイルを前記原本にマージした後、前記ブランチにおけるファイルの貸出及び返却をロックするステップを更に実現させることを特徴とする請求項２記載のファイル管理プログラム。
  5. 　前記第２のデータベースには、前記担当者の作業内容が更に関連付けられたことを特徴とする請求項１記載のファイル管理プログラム。
  6. 　前記コンピュータに、前記第２のデータベースに作業内容，作業の担当者及び作業対象となる少なくとも１つのファイルを関連付けて登録したときに、前記担当者に少なくとも作業内容を通知するステップを更に実現させることを特徴とする請求項１記載のファイル管理プログラム。
  7. 　原本を構成する各ファイルについて、ファイル名に対して少なくとも１つの版数及び保存先を関連付けて登録する第１のデータベースと、作業の担当者及び作業対象となる少なくとも１つのファイルを関連付けて登録する第２のデータベースと、を格納したストレージを有するコンピュータが、
    　ファイルの貸出依頼があったときに、前記貸出依頼に係る担当者が前記第２のデータベースに登録されているか否かを判定し、前記担当者が前記第２のデータベースに登録されていれば、前記担当者にファイルを貸し出すステップと、
    　ファイルの返却があったときに、前記返却に係る担当者及びファイルが前記第２のデータベースに登録されているか否かを判定し、前記担当者及びファイルが前記第２のデータベースに登録されていれば、前記ファイルを前記ストレージに新規保存すると共に、前記第１のデータベースについて、返却されたファイルのファイル名に対して版数及び保存先を追加登録するステップと、
    　返却されたファイルの承認が行われたとき、前記承認を経たファイルを前記原本にマージするステップと、
    　を実行することを特徴とするファイル管理方法。
  8. 　原本を構成する各ファイルについて、ファイル名に対して少なくとも１つの版数及び保存先を関連付けて登録する第１のデータベースと、
    　作業の担当者及び作業対象となる少なくとも１つのファイルを関連付けて登録する第２のデータベースと、
    　ファイルの貸出依頼があったときに、前記貸出依頼に係る担当者が前記第２のデータベースに登録されているか否かを判定し、前記担当者が前記第２のデータベースに登録されていれば、前記担当者にファイルを貸し出すファイル貸出部と、
    　ファイルの返却があったときに、前記返却に係る担当者及びファイルが前記第２のデータベースに登録されているか否かを判定し、前記担当者及びファイルが前記第２のデータベースに登録されていれば、前記ファイルをストレージに新規保存すると共に、前記第１のデータベースについて、返却されたファイルのファイル名に対して版数及び保存先を追加登録するファイル返却部と、
    　返却されたファイルの承認が行われたとき、前記承認を経たファイルを前記原本にマージする承認部と、
    　を有することを特徴とするファイル管理装置。
PCT/JP2010/064513 2010-08-26 2010-08-26 ファイル管理プログラム，ファイル管理方法及びファイル管理装置 WO2012026027A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2012530490A JPWO2012026027A1 (ja) 2010-08-26 2010-08-26 管理プログラム，管理方法及び管理装置
PCT/JP2010/064513 WO2012026027A1 (ja) 2010-08-26 2010-08-26 ファイル管理プログラム，ファイル管理方法及びファイル管理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/064513 WO2012026027A1 (ja) 2010-08-26 2010-08-26 ファイル管理プログラム，ファイル管理方法及びファイル管理装置

Publications (1)

Publication Number Publication Date
WO2012026027A1 true WO2012026027A1 (ja) 2012-03-01

Family

ID=45723054

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/064513 WO2012026027A1 (ja) 2010-08-26 2010-08-26 ファイル管理プログラム，ファイル管理方法及びファイル管理装置

Country Status (2)

Country Link
JP (1) JPWO2012026027A1 (ja)
WO (1) WO2012026027A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05265722A (ja) * 1992-03-19 1993-10-15 Fujitsu Ltd ソフトウェア情報資源の版数管理方法
JP2008003847A (ja) * 2006-06-22 2008-01-10 Fuji Xerox Co Ltd 文書利用管理システム、文書管理サーバ及びそのプログラム
JP2009301190A (ja) * 2008-06-11 2009-12-24 Fuji Xerox Co Ltd 文書処理装置及び文書処理プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05265722A (ja) * 1992-03-19 1993-10-15 Fujitsu Ltd ソフトウェア情報資源の版数管理方法
JP2008003847A (ja) * 2006-06-22 2008-01-10 Fuji Xerox Co Ltd 文書利用管理システム、文書管理サーバ及びそのプログラム
JP2009301190A (ja) * 2008-06-11 2009-12-24 Fuji Xerox Co Ltd 文書処理装置及び文書処理プログラム

Also Published As

Publication number Publication date
JPWO2012026027A1 (ja) 2013-10-28

Similar Documents

Publication Publication Date Title
US7653613B1 (en) Method and apparatus for facilitating simultaneous modifications to financial-data by multiple users
US9251183B2 (en) Managing tenant-specific data sets in a multi-tenant environment
CN101772764B (zh) 多线程业务编程库
EP3646529A1 (en) System and method for managing a public software component ecosystem using a distributed ledger
JP6499085B2 (ja) リソースの注釈
JP3512439B2 (ja) チェックイン・チェックアウトモデルにおける施錠方式
US10402378B2 (en) Method and system for executing an executable file
JP2006072986A (ja) データストアに対して動的に生成されるオペレーションを検証すること
US20190026307A1 (en) File metadata verification in a distributed file system
US11630647B2 (en) Method and system for configuring processes of software applications using activity fragments
JP2008009485A (ja) 仮想ストレージ制御装置及び仮想ストレージ制御プログラム
US20230259640A1 (en) Data storage systems and methods of an enforceable non-fungible token having linked custodial chain of property transfers prior to minting using a token-based encryption determination process
US9274719B2 (en) Snapshot management in hierarchical storage infrastructure
JPH1153243A (ja) コンピュータシステム及びその処理プログラムを記録した媒体
WO2015021478A1 (en) Preserving content in digital files
JP2006172377A (ja) ワークフローシステムおよび関連権限設定方法およびプログラムおよび記録媒体
WO2012026027A1 (ja) ファイル管理プログラム，ファイル管理方法及びファイル管理装置
JP2004178119A (ja) 情報管理システム
US10600008B2 (en) System implementing electronic case versioning
US8229908B2 (en) Dividing financial-data to facilitate simultaneous modifications by multiple users
JP5172585B2 (ja) オブジェクト・モデルに対するアクセスを制御するシステム、方法、およびプログラム
JP2009301190A (ja) 文書処理装置及び文書処理プログラム
JP2009104347A (ja) アクセス可能な電子文書を提供するアクセス制御装置
JPH08320782A (ja) ソフトウェア生産物の管理装置
JP5375410B2 (ja) リポジトリ管理装置、リポジトリ管理方法及びリポジトリ管理プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10856431

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012530490

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10856431

Country of ref document: EP

Kind code of ref document: A1