37
平成 22 年度 卒業論文 定型化された業務分析手法の教材化の研究 2 指導教官 寺町 康昌 教授 提出者 職業能力開発総合大学校 情報システム工学科 中村 祐貴 提出日 平成 22 2 18

学部卒業論文

  • Upload
    n-yuki

  • View
    1.521

  • Download
    0

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: 学部卒業論文

平成 22 年度 卒業論文

定型化された業務分析手法の教材化の研究 2

指導教官 : 寺町 康昌 教授

提出者 : 職業能力開発総合大学校 情報システム工学科

中村 祐貴

提出日 : 平成 22 年 2 月 18 日

Page 2: 学部卒業論文

第 1 章 序論 ................................................................................................................................................. 1

1.1 研究背景・目的 ................................................................................................................................. 1

1.2 構成 ................................................................................................................................................... 1

第 2 章 PEXA 方式...................................................................................................................................... 2

2.1 PEXA とは ........................................................................................................................................ 2

2.2 PEXA の特徴 .................................................................................................................................... 2

2.3 PEXA の概要 .................................................................................................................................... 2

2.3.1 PEXA Methodology ....................................................................................................................... 3

2.3.2 PEXA Engine ................................................................................................................................ 3

2.3.3 PEXA Tools .................................................................................................................................... 3

2.4 PEXA を使った基幹業務システムの開発 ........................................................................................ 3

2.4.1 業務分析プロセス .......................................................................................................................... 4

2.4.2 詳細分析プロセス .......................................................................................................................... 4

2.4.3 設計・実装・試験プロセス............................................................................................................ 4

第 3 章 SVO Statement.............................................................................................................................. 5

3.1 ユースケース..................................................................................................................................... 5

3.1.1 ユースケース図 .............................................................................................................................. 5

3.1.2 ユースケース記述 .......................................................................................................................... 6

3.2 SVO Statement ................................................................................................................................ 7

第 4 章 シナリオ・ドメイン表 ................................................................................................................... 9

4.1 シナリオ ............................................................................................................................................ 9

4.1.1 シナリオとは ................................................................................................................................. 9

4.1.2 シナリオの導出 .............................................................................................................................. 9

4.1.3 シナリオの確認 .............................................................................................................................. 9

4.2 ドメイン .......................................................................................................................................... 10

4.2.1 ドメインとは ............................................................................................................................... 10

4.2.2 ドメインの導出 ............................................................................................................................ 10

4.2.3 ドメインの確認 ............................................................................................................................ 10

4.3 シナリオ・ドメイン表 .................................................................................................................... 11

4.3.1 シナリオ・ドメイン表とは.......................................................................................................... 11

4.3.1 シナリオ・ドメイン表の作成 ...................................................................................................... 11

第 5 章 シーケンス図 ................................................................................................................................ 16

5.1 シーケンス図とは ........................................................................................................................... 16

5.2 シーケンス図の作成........................................................................................................................ 16

5.3 シーケンス番号の対応 .................................................................................................................... 30

第 6 章 教材の開発...................................................................................................................................... 32

6.1 交通費申請システム........................................................................................................................ 32

6.2 図書館システム ............................................................................................................................... 32

6.3 教材の利用 ...................................................................................................................................... 32

Page 3: 学部卒業論文

1 / 35

第 1 章 序論

1.1 研究背景・目的 現在,基幹業務システムは企業にとって業務を運用するのに不可欠なものとなっている.基幹業務シス

テムの開発は,ウォーターフォールモデルに従うと,要求分析,設計,実装,試験の4つのプロセスで行

われる.しかし,要求分析を正確に行うためには,要求分析を業務分析と詳細分析の二段階で行う必要が

ある.

業務分析手法を定型化すると,誰が業務分析を行っても同じように精度の良い分析結果となり,複数人

で並行して複数の業務を分析できるようになる.さらに,本研究で扱う方法論を使えば,短期間・低コス

トでプロトタイプを作成することができるため,システム開発プロセスが効率化する.

現在,実践的ソフトウェア教育コンソーシアムという組織が中心となって,大学などの教育機関で,ソ

フトウェア開発手法に関する教育を充実させようという取り組みが活発化してきている.その中で,本研

究が扱う方法論が注目されている.

そこで,本研究では定型化された業務分析手法を教育機関で修得できるようにするための教材作成を目

的とした.

1.2 構成

第 2 章では,PEXA を使った基幹業務システムの開発手法を記述する.第 3 章では,SVO Statement

が考案された経緯や,システムのプロトタイプが自動展開できる理由を記述する.第 4 章・第 5 章では

図書館システムを例として,帳票を扱う一般的な業務に対応できるような記述方法でシナリオ・ドメイン

表の作成方法やシーケンス図の作成方法を記述する.第 6 章では,実例として作成したシステムについて

説明する.

Page 4: 学部卒業論文

2 / 35

第 2 章 PEXA 方式

2.1 PEXA とは

PEXA とは Pattern Extensible Architecture の略で,システム開発(業務分析,詳細分析,設計,実装,

試験)を行うための開発手法である.

2.2 PEXA の特徴

企業は人・物・金で成り立っており,人から人への連絡(例:受注票)や物と金の関係(例:料金明細)

など,実態と実態をつなぐ場合に必ず帳票を用いるという考えから,PEXA では帳票を中心に業務を分析

する手法をとっている.

2.3 PEXA の概要

図 1 PEXA の概要

分析手法

・シナリオ・ドメイン表

・シーケンス図

PEXA Tools

分析成果物

(Engineへの入力)

・Model

・業務項目

・Process

・Interface

・Rule

(中間成果物)

PEXA Engine

プロトタイプ(チューニング)

PEXA Methodology

Page 5: 学部卒業論文

3 / 35

2.3.1 PEXA Methodology

PEXA Methodology とは業務分析アプリケーション開発手法である.システム開発の手順は業務分析,

詳細分析,設計,実装,試験の各プロセスで構成されている.PEXA Methodology と後述する PEXA Tools

を使うと,SVO Statement,アクティビティシート,サービス定義書などの成果物を導出することがで

きる.

2.3.2 PEXA Engine

PEXA Engine は PEXA Methodology で導出された成果物を読み込み,解釈し,動作する JAVA によ

る実行エンジンである.プログラム言語を極力減らした成果物を読み込むことで,上流工程と実装との乖

離を防ぎ,プログラマに寄り過ぎないエンドユーザー向けの仕様を実現している.

2.3.3 PEXA Tools

PEXA Tools は PEXA Methodology で成果物を導出するための補助やテストの支援をする機能,PEXA

Methodology で導出した成果物を PEXA Engine で解釈できる形へ変換する機能,PEXA でのシステム

開発プロジェクトにおけるタスク管理機能の 3 つの機能を有している.

2.4 PEXA を使った基幹業務システムの開発

図 2 PEXA を使った基幹業務システムの開発

基幹業務システムの開発プロセスは,ウォーターフォールモデルに従うと,要求分析,設計,実装,試

験の4つに分類される.しかし,要求分析を正確に行うためには,要求分析を業務分析と詳細分析の二段

階で行う必要がある.そこで PEXA におけるシステム開発モデルではシステム開発プロセスを,業務分

析,詳細分析,設計,実装,試験の 5 つのプロセスに分類する.

要求分析

詳細分析

業務分析

ウォーターフォールモデル

PEXA

Page 6: 学部卒業論文

4 / 35

2.4.1 業務分析プロセス

業務分析プロセスでは,後述するシナリオ・ドメイン表を作成し,それに基づいて帳票の流れだけを記

述した業務フロー図を作成する.これを行うことで,業務全体の流れを分析する.また,業務分析には現

状分析である As-Is 業務分析とシステムのあるべき姿を考える To-Be 業務策定の 2 つがある.

2.4.2 詳細分析プロセス

詳細分析プロセスでは,帳票の流れだけを記述した業務フロー図に業務項目を追加していく.ここまで

できれば,PEXA Methodology に従いシステムのプロトタイプを自動展開することができる.また,作

成された業務フロー図には業務が帳票の流れに注目して記述されているため,テストシナリオとしても利

用可能である.これらを用いてクライアントによる検証を行い,システムの問題点を洗い出す.

2.4.3 設計・実装・試験プロセス

詳細分析プロセスで明確化された問題点は,Model(抽象化された帳票),業務項目(全帳票の全個別

データ項目),Interface(画面),Rule(計算によって自動的に作成される業務項目),Process(処理の

流れ)という 5 つの要素に手を加えることにより解決する.

Page 7: 学部卒業論文

5 / 35

第 3 章 SVO Statement

3.1 ユースケース

一般的なユースケースには,ユースケース図とユースケース記述がある.

3.1.1 ユースケース図

図 3 ユースケース図

ユースケース図とは業務分析の際に使用する図である.基幹業務システムではユースケース数が 1000

ぐらいになるため,クライアント側にとってはシステムの動作がわかりやすいが,開発者側には業務の流

れがわかりづらい図である.

交通費申請システム

交通費申請書

を受付ける

交通費申請書

を承認する

交通費申請書

を作成する

社員

事務

上長

Page 8: 学部卒業論文

6 / 35

3.1.2 ユースケース記述

表 1 ユースケース記述

ユースケース記述とはユースケース図を文章として表に記述したものである.基幹業務システムではユ

ースケース数が 1000 ぐらいになるため,開発者側にとっては業務の流れがわかりやすいが,クライアン

ト側にはシステムの動作がわかりづらい図である.

アクターが、交通費申請書を受付けない 代替フロー

アクターが、交通費申請書を受付ける 基本フロー

交通費申請書が受付済みである状態 事後条件

交通費申請書が作成済みである状態 事前条件

事務が交通費申請書を受付ける 目的

事務 アクター

事務が交通費申請書を受付ける ユースケース名

アクターが、交通費申請書明細に明細金額、行先、移動日、移動手段を入力

アクターが、交通費申請書に申請日、合計金額を入力 基本フロー

交通費申請書が作成済みである状態 事後条件

アクターが交通費を申請できる状態 事前条件

アクターが交通費を申請する 目的

社員 アクター

社員が交通費申請書を作成する ユースケース名

Page 9: 学部卒業論文

7 / 35

3.2 SVO Statement

図 4 SVO Statement

REJECT 返却する ST_001034

UNSUSPEND 保留解除する ST_001033

SUSPEND 保留する ST_001032

UNACCEPT 受付取消/承認取消する ST_001031

ACCEPT 受付/承認する 交通費申請書 上長 PASSIVE_ACCEPT 交通費申請書承認者 ST_001030

REJECT 返却する ST_001024

UNSUSPEND 保留解除する ST_001023

SUSPEND 保留する ST_001022

UNACCEPT 受付取消/承認取消する ST_001021

ACCEPT 受付/承認する 交通費申請書 事務 PASSIVE_ACCEPT 交通費申請書受付者 ST_001020

REMOVE 削除する ST_001012

UPDATE 更新する ST_001011

CREATE 生成する 交通費申請書 社員 ACTIVE 交通費申請書作成者 ST_001010

操作タイプ 操作名 イニシアティブターゲット 参加

ロールタイプ ロール ID

S O V

Page 10: 学部卒業論文

8 / 35

表 2 帳票操作

ロールカテゴリ ロールタイプ 操作タイプ

ACTIVE ACTIVE CREATE

UPDATE

REMOVE

PASSIVE PRODUCE PRODUCE

CANCEL

ACCEPT ACCEPT

UNACCEPT

SUSPEND

UNSUSPEND

REJECT

SEND

RECEIVE

EDIT EDIT

ROLLBACK

STATUS ENABLE

DISABLE

REFERENCE SEARCH SEARCH

PORTFOLIO SEARCH

CONTROL ACTIVE CREATE

UPDATE

ENABLE

DISABLE

REMOVE

REFERENCE SEARCH

SVO Statement とはユースケース記述を S(ロール),V(操作),O(操作形式)に明確に分けたもの

である.このとき,O は帳票(伝票,帳簿,マスタファイル)である.また S は“O”+“V”+“者”で,組織

や人から離れて権限だけを抽象化したものになる.官庁などでは業務の担当組織が毎年変わるが,S をロ

ールにするとユースケースを使える人のポインタを変えるだけでいいということになる.表 1 のように各

ロールには,ACTIVE,PASSIVE,REFERENCE,CONTROL の 4 つのカテゴリがある.ACTIVE は,

元になる帳票(O)なしに能動的に帳票を作成する.PASSIVE は何らかの帳票を受けて処理を行う.

企業内ではほとんどの人が PASSIVE になる.REFERENCE は帳票の参照・集計などを行う.CONTROL

は主にマスタファイルの変更を行う.また,ACTIVE の役割には CREATE,UPDATE,REMOVE の操

作が可能である.このように,O を帳票に限定すると,その O を扱う役割 S も4種類に限定される.さ

らに,S の処理操作である V も 22 種類に限定される.その結果,SVO Statement が記述できると,帳

票を扱うシステムアプリケーションを自動的に展開することができる.しかし,SVO Statement を用い

て業務分析を行っても,クライアントに理解してもらうことは困難であった.そこで,業務分析のツール

としてシナリオ・ドメイン表とシーケンス図が考案された.

Page 11: 学部卒業論文

9 / 35

第 4 章 シナリオ・ドメイン表

4.1 シナリオ

4.1.1 シナリオとは

シナリオとは依頼者に権限のある依頼,あるいは依頼に対して提供されるサービスのことである.情報

システム化を前提とせずに,業務全体をターゲットに記述することが重要である.また,権限とは依頼者

が選択できる権利のことである.

4.1.2 シナリオの導出

外部から顧客への依頼を列挙していく.ただし,あくまで権限を有する依頼なので,すべての依頼がシ

ナリオになるとは限らない.例えば交通費申請後の「支払い」は権限を有しておらず,承認が完了して初

めて支払いが行われるので,シナリオにはならない.

※ シナリオを正しく導出できるようになるためには,経験の蓄積が必要となる.

4.1.3 シナリオの確認

様々な方法でシナリオが正しいか確認を行う.

・ 顧客が依頼するしないを決定する権限を有するか

・ 「~を依頼する」という形に置き換えられるか

・ 一度に申し込まないと意味がないものは 1 つのシナリオで表しているか

・ 顧客の依頼と直接関係がないものを記述していないか

・ 事故が発生した場合に対する対応も考えているか

・ シナリオに対して発生するドメイン(後述)が正しく存在するか

Page 12: 学部卒業論文

10 / 35

4.2 ドメイン

4.2.1 ドメインとは

ドメインとは各部署がシナリオを実現するために行う業務のことである.

4.2.2 ドメインの導出

シナリオを実現するために,どのような業務が必要なのかを分析し列挙していく.

※ ドメインを正しく導出できるようになるためには,経験の蓄積が必要となる.

4.2.3 ドメインの確認

様々な方法でドメインが正しいか確認を行う.

・ ドメイン内で正しくその業務が完了しているか

・ 人,物,金の流れでできているか

・ 完了形や「~タスク」という形に置き換えられるか

Page 13: 学部卒業論文

11 / 35

4.3 シナリオ・ドメイン表

4.3.1 シナリオ・ドメイン表とは

シナリオ・ドメイン表とは利用者に対するサービス(シナリオ)と業務のつながりを明確にし,分析の

対象範囲及び業務(ドメイン)がカバーされているかの確認を行い,さらに次工程(シーケンス図)にお

ける領域の見積もりを行うために作成する表である.

4.3.2 シナリオ・ドメイン表の作成

① Microsoft Excel を起動

② 想定されるシナリオ(利用者に対するサービス)を記述

図書館システムの場合,

・ 利用者情報登録依頼

・ 書籍購入依頼

・ 書籍寄贈依頼

・ 書籍紛失申告

・ 書籍検索

・ 書籍貸出依頼

・ 書籍貸出予約依頼

・ 書籍返却依頼

・ 他図書館から検索依頼

・ 他図書館への書籍予約依頼

・ 他図書館から書籍予約依頼

の 11 個のシナリオが必要となる.

図 5 シナリオの記述

Page 14: 学部卒業論文

12 / 35

③ 想定されるドメイン(シナリオに対して発生する業務)を記述

図書館システムの場合,

・ 利用者情報登録

・ 発注先登録

・ 書籍購入依頼作成

・ 書籍発注作成

・ 書籍入荷

・ 請求受付

・ 支払

・ 書籍寄贈受付

・ 書籍紛失受付

・ 紛失書籍抹消

・ 書籍検索

・ 書籍貸出作成

・ 書籍返却

・ 書籍予約依頼作成

・ 書籍到着連絡

・ 書籍予約貸出

・ 書籍返却依頼作成

・ 利用者利用停止

・ 他図書館書籍取寄依頼

・ 他図書館書籍取寄受付

・ 他図書館へ返却

・ 他図書館へ送付

の 22 個のドメインが必要となる.

図 6 ドメインの記述

Page 15: 学部卒業論文

13 / 35

④ シナリオ毎に関連するドメインに○をつける.

※ 例外的に関連するドメインには●をつける.

図 7 シナリオ・ドメイン表に○をつける

⑤ シナリオ・ドメイン表の不足・重複の確認

様々な方法でシナリオ・ドメイン表が正しいか確認する.

・ ドメインの取り扱い対象からシナリオに漏れがないか

・ シナリオを分割できる可能性がないか

・ ドメインを分割できる可能性がないか

・ シナリオを統合できる可能性がないか

・ ドメインを統合できる可能性がないか

・ シナリオの一部がドメインになっていないか

・ ひとつのシナリオにしか○がついていないドメインは,他に同じようなドメインがないか

・ 同じ「注文」であっても,異なる種類の注文ではないか

⑥ シナリオやドメインの削除

シナリオやドメインを削除する場合は,表のなかで色を変えるか不可視にして表に残す.また,

消した理由をコメントにして残しておく.これは,消した理由を他者に理解させ,消したものを

再度追加しないようにするためである.

Page 16: 学部卒業論文

14 / 35

⑦ シナリオ・ドメイン表の中でシステム化する部分を決定する

図 8 システム化する部分の決定

今回システム化する部分は,

シナリオでは,

・ 利用者情報登録依頼

・ 書籍購入依頼

・ 書籍寄贈依頼

・ 書籍貸出依頼

・ 書籍貸出予約依頼

ドメインでは

・ 利用者情報登録

・ 発注先登録

・ 書籍購入依頼書作成

・ 書籍発注書作成

・ 書籍寄贈書作成

・ 書籍入荷

・ 書籍貸出書作成

・ 書籍返却

・ 書籍予約依頼書作成

・ 書籍到着連絡

・ 書籍予約貸出

・ 書籍返却依頼書作成

とする.

※ 今回システム化しない部分というのは,システム化する部分に比べ発生する確率が低い部分

や,システム化する部分にすでに含まれている部分である.

Page 17: 学部卒業論文

15 / 35

システム化する部分だけを抽出すると,図 9 のようになる.

図 9 システム化する部分のシナリオ・ドメイン表

これでシナリオ・ドメイン表が完成となる.これを元に,ドメインごとにシーケンス図を作成していく.

Page 18: 学部卒業論文

16 / 35

第 5 章 シーケンス図

5.1 シーケンス図とは

シーケンス図とは SVO Statement をクライアントにわかりやすいように,帳票の流れを使って記述し

た図である.

5.2 シーケンス図の作成

PEXA のシーケンス図は,Astah のアクティビティ図を用いて作成する.

① Astah のインストール

astah-community-6_1-jre-setup.exe をダブルクリック

② Astah の実行

・ ファイル – プロジェクトの新規作成

・ 構造ツリーの一番上のフォルダ(no_title)を右クリック – 図の追加 – アクティビティ図の

追加

※ シーケンス図の追加を選ばない.(PEXA のシーケンス図は Astah のアクティビティ図で作

成する.)

図 10 プロジェクトの新規作成

Page 19: 学部卒業論文

17 / 35

図 11 アクティビティ図の追加

③ ロールの作成

PEXA のロールは,アクティビティ図のパーティションを使って記述する.

・ アクティビティ図の上にあるリストの中の「パーティション〔縦〕」をクリック

・ 下の act アクティビティ図 0 と書かれた枠の範囲内でクリック

これでロールがひとつ作成される.

図 12 ロールの作成 1

パーティション〔縦〕

Page 20: 学部卒業論文

18 / 35

二つ目以降は,

・再びパーティション〔縦〕をクリック

・下の act アクティビティ図 0 と書かれた枠の範囲内の,先ほど作成したロールの右側でクリッ

これで二つ目のロールが作成される.

図 13 ロールの作成 2

図 14 ロールの作成 3

※ ロール名について

ロール名は最初パーティション 0 のようになっているが,これを「O を V する者」に変更

する.また,:の後にそのロールの動作を表す.

例) 利用者情報登録ドメインの場合

利用者情報登録者:作成

Page 21: 学部卒業論文

19 / 35

④ 帳票の記述

PEXA では O(目的語)を帳票に限定する.それにより,その O を扱う S(役割)も 4 種類に

限定される.

・ ACTIV…何もないところに,帳票を作成する

・ PASSIVE…何らかの帳票を受けて処理を行う

・ REFERENCE…帳票の集計などを行う

・ CONTROL…主にマスタファイルの変更を行う

また,PASSIVE は 5 種類に分けられる

・ PASSIVE_PRODUCE…元になる帳票から,別の帳票を導出する

・ PASSIVE_ACCEPT…帳票の状態区分を変更し,別のロールに流す

・ PASSIVE_SEND…異なったドメインに帳票を送信する

・ PASSIVE_RECEIVE…異なったドメインから帳票を受信する

・ PASSIVE_EDIT…受け取った帳票を編集する(官庁クラスの権限が必要)

今回の図書館システムでは主に,ACTIV,PASSIVE_PRODUCE,PASSIVE_ACCEPT を用い

る.

I. ACTIV の記述

PEXA で帳票は,アクティビティ図のアクションを使って記述する.

・ アクティビティ図の上にあるリストの中の「アクション」をクリック

・ 作成したロールの中でクリック

図 15 帳票の記述(ACTIV)1

アクション

Page 22: 学部卒業論文

20 / 35

帳票を記述するに当たって必要な情報を入力する.

・ 作成されたアクションをクリック,左にある「入力動作」タブをクリック

・ 入力動作に必要な情報を入力

帳票名 ( 帳票の状態区分 ; 状態区分の値 )

例) 利用者情報 Master(利用者状態区分;作成済)

※ 直接帳票の中に入力すると,PEXA に反映されない可能性があるため,必ず上記の手順

で入力を行う.

図 16 帳票の記述(ACTIV)2

・ わかりやすいように,帳票に色を塗る(ACTIVE はオレンジ)

図 17 帳票の記述(ACTIV)3

Page 23: 学部卒業論文

21 / 35

帳票には,機能コメントをつけることができる.

機能コメントを使うと,帳票の業務項目を追加したり変更したりすることができる.

機能コメントはアクティビティ図のノートを使って記述する.

・ アクティビティ図の上にあるリストの中の「ノート」をクリック

・ 機能コメントをつけたい帳票があるロールの中でクリック

・ 帳票と「ノート」を点線でつなぐ

図 18 帳票の記述(ACTIV)4

今回の図書館システムでは帳票につける機能コメントとして,<<edit>>,<<search>>を用いる.

Ⅰ-Ⅰ <<edit>>

機能コメント<<edit>>は,帳票に業務項目の値を入力する際に用いる.

ノートを選択し,左下のステレオタイプタブに edit,ベースタブに以下の a~c にした

がって業務項目と値を入力する.

a. 手入力させる場合

入力したい業務項目名 ;input/ 画面に表示されるテキストボックス名

例)AAA ;input/ BBB

→ 画面上の BBB と表示されているテキストボックスに入力したものが,業務項目

AAA の値として設定される.

b. プルダウンメニューから選択させる場合

入力したい業務項目名 % プロキシ・現象名 ? 値 1 ? 値 2 ;input/ 画面に表示されるプルダウンメニュー名

※今回,入力したい業務項目名とプロキシ・現象名は同じものとする.

例)AAA % AAA ? BBB ? CCC ? ;input/ DDD

→ 画面上の DDD と表示されているプルダウンメニューに BBB と CCC の選択肢が

表示され,選択したものが業務項目 AAA の値として設定される.

c. 代入させる場合

入力したい業務項目名 ; 入力したい値

例)AAA ; BBB

→ BBB が,業務項目 AAA の値として設定される.

ノート 点線

Page 24: 学部卒業論文

22 / 35

図 19 帳票の記述(ACTIV)5

Ⅰ-Ⅱ <<search>>

機能コメント<<search>>は,帳票を参照し,その中で選択した項目のデータ No(利

用者情報 Master の場合は利用者情報 No)を指定した帳票に入力する際に用いる.

ノートを選択し,左下のステレオタイプタブに search,ベースタブに以下の書式にした

がって検索したい帳票名や業務項目などを入力する.

帳票名 ( 検索したい業務項目名 ;input/ 画面に表示されるテキストボックス名 )

入力するデータ No 名 ; 参照したデータ No 名

例)AAA Master ( BBB ;input/ CCC ) DDD No ; EEE No

→ 画面上のCCCと表示されているテキストボックスの右にある参照ボタンをクリッ

クし,帳票の参照画面を開く.業務項目 BBB の値で AAA Master 内を検索し,選択し

たデータのデータ No である EEE No を指定した帳票に DDD No として入力する.

Page 25: 学部卒業論文

23 / 35

図 20 帳票の記述(ACTIV)6

II. PASSIVE_PRODUCE の記述

元になる帳票から,別の帳票を導出することを PASSIVE_PRODUCE という.

・ 元になる帳票の下に,導出したい帳票を記述する

・ わかりやすいように,導出先の帳票に色を塗る(PASSIVE_PRODUCE は黄色)

(ACTIVE で作成した帳票と PASSIVE_PRODUCE で作成した帳票は別の色にする.)

・ 導出もとの帳票から,導出先の帳票に矢印を引く

図 21 帳票の記述(PASSIVE_PRODUCE)1

矢印

Page 26: 学部卒業論文

24 / 35

PASSIVE_PRODUCE の際には,機能コメント<<copy>>をつけることができる.

機能コメント<<copy>>を使うと,導出もとの帳票の業務項目の値を導出先の帳票に入力するこ

とができる.

ノートを選択し,左下のステレオタイプタブに copy,ベースタブに以下の書式にしたがってコ

ピーしたい業務項目を入力する.

コピー先の業務項目名 ; コピーもとの業務項目名

例)AAA ; BBB

→ もとの帳票の業務項目 BBB の値が,導出される帳票の業務項目 AAA の値として

設定される.

図 22 帳票の記述(PASSIVE_PRODUCE)2

III. PASSIVE_ACCEPT の記述

帳票の状態区分を変更し,その帳票を別のロールに流すことを PASSIVE_ACCEPT とい

う.

・ 帳票を流したいロールを作成する

・ 帳票を流したいロールに,帳票を状態区分の値を変更して記述する

・ 流す前の帳票から,流した後の帳票に矢印を引く

Page 27: 学部卒業論文

25 / 35

図 23 帳票の記述(PASSIVE_ ACCEPT)

図 24 システムの実行画面

※ 状態区分について

PEXA tools では帳票の状態区分が,SVO statement の前提条件と終了条件になる.

前提条件 SVO statement 終了条件

前提条件が満たされたときに検索ボタンを押すと帳票が画面に表示され,終了条件を満たしたときに

検索ボタンを押すと画面から消えるようになっている.

また,帳票の状態区分が変わるのは OK ボタンを押してロールを終了したときである.

図 25 の場合,書籍購入依頼の購入依頼状態区分が作成済になることが,ロール:書籍購入依頼受付

者に書籍購入依頼が表示される前提条件となる.

帳票

検索ボタン

OKボタン

Page 28: 学部卒業論文

26 / 35

また,購入依頼状態区分が受付済になることが,ロール:書籍購入依頼受付者に書籍購入依頼が表示

されなくなる終了条件となる.

IV. 異なったファイル間の PASSIVE_ACCEPT(シグナル送信アクション)

シグナル送信アクションを使うと,以降に記述するシーケンス番号を対応させることで,

送信したいドメインが別のシーケンスファイルであっても送信することができる.

・ アクティビティ図の上にあるリストの中の「シグナル送信アクション」をクリック

・ 送信したい帳票があるロールの中でクリック

・ 帳票から作成したシグナル送信アクションに矢印を引く

・ シグナル送信アクションを選択し,左にあるステレオタイプタブが signal sending に

なっていることを確認,入力動作タブに以下の書式にしたがってシナリオ名とドメイン名を

入力する.

帳票を送信したいシナリオ名 帳票を送信したいドメイン名 ドメインへ

例)帳票を書籍発注作成ドメインへ送信したい場合,シナリオ・ドメイン表を見ると,書籍

発注作成ドメインは書籍購入依頼シナリオに対して発生するドメインなので,

書籍購入依頼書籍発注作成ドメインへ となる.

図 25 帳票の記述(シグナル送信アクション)

V. 異なったファイル間の PASSIVE_ACCEPT(イベント受信アクション)

シグナル送信アクションで送信した帳票をイベント受信アクションで受信する.

・ アクティビティ図の上にあるリストの中の「イベント受信アクション」をクリック

・ 受信したい帳票があるロールの中でクリック

・ 作成したイベント受信アクションから帳票に矢印を引く

・ イベント受信アクションを選択し,左にあるステレオタイプタブが signal receipt にな

っていることを確認,入力動作タブに以下の書式にしたがってシナリオ名とドメイン名を入

力する.

シグナル送信アクション

Page 29: 学部卒業論文

27 / 35

帳票を受信したいシナリオ名 帳票を受信したいドメイン名 ドメインから

例)帳票を書籍購入依頼作成ドメインから受信したい場合,シナリオ・ドメイン表を見ると,

書籍購入依頼作成ドメインは書籍購入依頼シナリオに対して発生するドメインなので,

書籍購入依頼書籍購入依頼作成ドメインから となる.

図 26 帳票の記述(イベント受信アクション)

VI. before_condition の記述

普通帳票は何もないところから新たに作成する(ACTIVE)か,別の帳票をもとに新しい帳票

を作成する(PASSIVE)かのどちらかで記述する.しかし,すでにある帳票を状態区分を変更

せずに再び記述する必要がある場合は帳票に<<before_condition>>という機能をつける.これを

使うと,帳票の中で指定した条件に当てはまるデータだけを表示させることができるため,その

中からひとつ選び指定する.

表示させたい帳票を選択し,左にあるステレオタイプタブに before_condition と入力し,入力

動作タブには以下の書式にしたがって条件などを入力する.

表示させたい帳票名 ( 条件の指定 )

例)AAA ( BBB ; CCC , DDD ;input/ EEE )

→ AAA の中で,業務項目 DDD の値が画面上の EEE と表示されているテキストボッ

クスに入力したものと等しく,かつ業務項目 BBB の値が CCC のものを表示する.

イベント受信アクション

Page 30: 学部卒業論文

28 / 35

図 27 帳票の記述(before_condition)1

<<before_condition>>で指定した帳票は,帳票自体に<<edit>>の機能を使うことで業務項目

の値を変更できる.

<<before_condition>>で記述した帳票の下に同じ帳票を記述し選択する.左のステレオタイプタ

ブに edit と入力し,入力動作タブには以下の書式にしたがって業務項目と値を入力する.

帳票名 ( 業務項目名 ; 値 )

例)AAA ( BBB ; CCC , DDD ; EEE )

→ 帳票 AAA の,業務項目 BBB の値を CCC に,業務項目 DDD の値を EEE にする.

図 28 帳票の記述(before_condition)2

Page 31: 学部卒業論文

29 / 35

図 28 の例だと,書籍蔵書 List の中で貸出区分が未貸出でかつ予約区分が未予約の書籍が画面

上に表示され,その中で指定した書籍の貸出区分を貸出済にする.

しかし,別の帳票との矢印の間に<<R>>という機能をつけることで,その帳票の業務項目であ

る書籍蔵書 No と同じ書籍蔵書 No をもつ書籍を直接指定することができる.

矢印を選択して,左のステレオタイプタブに以下の書式にしたがってデータ No を入力する.

R( 矢印もとのデータ No ; 矢印先のデータ No )

例)R( AAA No ; BBB No )

→ 矢印先の帳票のBBB Noの中で,矢印もとの帳票のAAA Noの値と等しいものを指定する.

図 29 帳票の記述(before_condition)3

図 29 の例だと,書籍蔵書 List の中で貸出区分が未貸出でかつ予約区分が未予約の書籍の中で,書

籍予約依頼の書籍蔵書 No と同じ書籍蔵書 No である書籍の貸出区分を貸出済にする.

Page 32: 学部卒業論文

30 / 35

5.3 シーケンス番号の対応

一般的にシーケンスファイルは,シナリオ・ドメイン表のドメインごとに分けて作成する.

図書館システムでは,

・ 000000000000 利用者情報登録

・ 000001001000 発注先登録

・ 000001002000 書籍購入依頼作成

・ 000001003000 書籍発注書作成

・ 000002004000 書籍寄贈書作成

・ 000002005000 書籍入荷

・ 000003006000 書籍貸出作成

・ 000004007000 書籍返却

・ 000004008000 書籍予約依頼作成

・ 000004009000 書籍到着連絡

・ 000004010000 書籍予約貸出

・ 000004011000 書籍返却依頼作成

という 12 個のシーケンスファイルを作成する.

シーケンスファイルには,先頭に 12 桁の数字で始まる名前をつける.

この 12 桁の数字は 3 桁ごとに下のような意味を持つ.

・ 先頭 1~3 桁…分類(共通,商標,団体商標,特許など)

・ 先頭 4~6 桁…シナリオ

・ 先頭 7~9 桁…ドメイン

・ 先頭 10~12 桁…トリガー書類名

特に,先頭 4~6 桁のシナリオと先頭 7~9 桁のドメインは,PEXA の中にある PexaWorksSetup.xls

のシナリオ分類コードとドメイン番号に対応させる必要がある.

※ PexaWorksSetup.xls は C:¥workspace¥kensyu¥tool¥jude¥config の中にある.

図書館システムのシーケンス図のシーケンス番号に対応するように,PexaWorksSetup.xls のシナリオ

分類コードとドメイン番号を変更し,シナリオ名称とドメイン名称を作成したシナリオ・ドメイン表をも

とに入力する.(図 30)(図 31)

図 30 シナリオシート

Page 33: 学部卒業論文

31 / 35

図 31 ドメインシート

Page 34: 学部卒業論文

32 / 35

第 6 章 教材の開発 定型化された業務分析手法を修得するためには,分析手法だけではなく,業務そのものを理解する必要

がある.しかし経営業務を知らない学生が業務を理解することは非常に困難である.そこで実例をもとに

業務分析を行い,実際に業務システムのプロトタイプを学生に作成させる必要がある.そこで,実例とし

て交通費申請システムと図書館システムを作成しその手順書を作成した.

6.1 交通費申請システム

交通費申請システムは,旅費や交通費を会社に請求する際の一連の流れをシステム化したものである.

付録 2 に交通費申請書作成手順書を載せる.

– ロール数 :6

– 帳票数 :4

– 業務項目数 :20

6.2 図書館システム

図書館システムは書籍入荷,書籍貸出,予約,返却依頼など図書館の機能をシステム化したものである.

付録 3 に図書館システム作成手順書を載せる.

– ロール数 :17

– 帳票数 :11

– 業務項目数 :81

6.3 教材の利用

教材は,職業訓練指導員,本大学校学生を対象としている.また,この教材は 3 日から 1 週間の期間

をかけて行われる講習会で利用される.

Page 35: 学部卒業論文

33 / 35

謝辞

本研究を行うにあたり,1 年の永きに渡って親身のご指導をいただきました,職業能力開発総

合大学校情報システム工学科寺町康昌教授に心から厚く御礼申し上げます.

また,PEXA による業務システム分析法に関する資料の御提供,並びに懇切な御指導と御助言

をしてくださいました株式会社アトリスの大内隆信氏,丹郁夫氏,および向井清氏に心から厚く

御礼申し上げます.

本当に有難うございます.

Page 36: 学部卒業論文

34 / 35

参考文献

木村 遼太郎,“ユースケースを用いた要求分析法の研究”,平成 21 年度 卒業論文

「要求分析を重視した設計手法と分析・設計方法論」説明会講演記録,平成 22 年 10 月,東

京都渋谷区桜丘町 22-14 NES ビル N6F

Page 37: 学部卒業論文

35 / 35

付録

1. PEXA 導入手順書

2. 交通費申請システム作成手順書

3. 図書館システム作成手順書