基礎情報技術 ー第2日目ー

基礎情報技術
ー第2日目ー
平成20年5月9日(金)
担当:亀田
確認
• 授業で使用した資料は授業終了後にWebに
て公開します。
• ノートにメモを取ってください。
(キーワードや図だけでも結構です。)
• 毎回レポート課題がでます。
(前回のレポートは授業終了時に回収しま
す。)
それでは始めましょう
前回のポイントの確認
• ITのプロになるためには何が必要か?
これを考えるための素材をお話しました。
前回のポイントの確認
•
•
•
•
SEの仕事はプログラミングだけではない
ソフトウェアのライフサイクル
オブジェクト指向
モデリング言語 UML など
授業概要
• ITエンジニアのプロフェッショナルになるためには、プロとして
の嗜み(たしなみ)と作法を身につけることも大切である。本
授業では、今後プロとしてソフトウェアかかわる人たちにとっ
て避けて通ることのできない嗜み・作法を簡単な演習を通じ
て紹介するとともに、学生の皆さんにそれらの必要性・重要
性を身を持って理解してもらうことを目指す。
• 具体的には、ソフトウェア開発を上流工程から下流工程へ向
けて実際に体験してもらいながら、UML(Unified Modeling
Language)やプロジェクト管理等の紹介を行う。
• ITシステム ≠ プログラミング であることや、ソフトウェア開発
におけるコミュニケーションの意義、プロジェクト管理の重要
性についてなど、多くのことを学生の皆さん自らが気づくこと
を期待する。
今日の内容
• 要求仕様を作ってみよう
• ソフトウェア開発過程の概要
• UMLの概説
• Javaプログラミング など
• 今日の課題(課題番号No2)
ソフトウェア開発過程の概要
• 「ソフトウェアは実際にどのような作業工程を
経て作れば良いのか?」 ということ。
ソフトウェア開発過程の確立
これは未解決問題
の1つです!
よいプログラムは
どうやって作れば良いのか?
•
•
•
•
•
•
•
バグのない
動作効率のよい
開発コストがかからない
メンテナンスがしやすい
急な修正・変更にも対応できる
拡張性のある
汎用性のある などなど
こんなプログラムって
どうやって作る
のだろうか?
例えば、プログラミング言語
これにもいろいろな工夫がなされてきた
• 事務処理計算向き言語
• 科学技術計算向き言語
• 人工知能研究向き言語 など
(こんな分類のもと、さまざまな言語が考案さ
れてきた。)
疑問:プログラミング言語の分類は今後もこれでいいのだろうか?
要求仕様としては…
• 対象としている処理(機能・サービス)を記述・
実現することができなければならない。
• 人間にとって使いやすく、分かりやすいもので
あって欲しい。
Fortran:計算式をそのまま書ける
Cobol:自然言語に近い表現が可能
Pascal: ____________________
C: ________________________
Java: ______________________
考えてみて
ください。
よりよいプログラムをもとめて…
•
•
•
•
機能の整理
モジュール化/階層化
構造化プログラミング
モジュールの独立性
(関数型言語、データ抽象化、
=>オブジェクト指向)
• ソフトウェア開発法
プログラミング
言語側から
開発法側から
具体的に見てみよう
• プログラミングの側面から
• 開発手法の側面から
プログラム工学Ⅲ
(ダイジェスト版)
工学部情報工学科での講義資料より
担当:亀田弘之(東京工科大学)
C言語の歴史
•
•
•
•
•
•
•
1972年 誕生(Dennis M. Ritchie)
UNIX開発用言語として使用
ハードウェアの発達により新しい機能追加
方言の発生
1989年 ANSI規格制定
1990年 ISO規格制定
1993年 JIS C制定
問題
1. C言語は今後どのような発展の道をたどる
か論じなさい。
2. BASIC、PASCAL、FORTRAN、COBOL、
LISP、PROLOGなどの他の言語の歴史を
調べ、各言語がどのような背景・目的で誕
生し、どのような道をたどっているか論ぜよ。
C言語の特徴
1.
2.
3.
4.
5.
6.
構造化プログラミング向き
ハードウェアが透けて見える高水準言語
豊富なデータタイプ
コンパクトな言語仕様
関数形式によるモジュール化
移植性が比較的高い
構造化プログラミングとは
• 処理手続きをいくつかの単位に分割し、主と
なる処理は大まかに記述とし、細部はサブ
ルーチンとして記述していく方法。エドガー・ダ
イクストラらによって提唱された。ダイクストラ
は、大規模化したプログラムを効率よく記述し
プログラム設計上のミスが起きにくいようにす
るための方法論を検討した。その結果1960
年代後半に、構造化定理を証明し、構造化プ
ログラミングを提唱した。
構造化定理
• 1つの入り口と1つの出口を持つようなプログ
ラムは、「順次・反復・分岐」の3つの基本的な
論理構造によって記述できる(Dijikstra)。
順次
反復
分岐
順次
S=S+1
X = f(S, 5)
S = g(X) + S
反復
分岐
問題
1. C言語の特徴を、Javaなどの他の言語と比
較して述べよ。
3.プログラムの基本的なパターン
#include <stdio.h>
main( ) {
本体
}
3.プログラムの基本的なパターン
#include <stdio.h>
main( ) {
double fahrenheit; /* 華氏 */
double celsius;
/* 摂氏 */
scanf(“%f”, &fahrenheit);
celsius = ( fahrenheit – 32 )*5.0/9.0;
printf(“%f”, celsius);
}
3.プログラムの基本的なパターン
Cのプリプロセッサ用
#include <stdio.h>
main( ) {
double fahrenheit; /* 華氏 */
double celsius;
/* 摂氏 */
scanf(“%f”, & fahrenheit);
celsius = ( fahrenheit – 32 )*5.0/9.0;
printf(“%f”, celsius);
}
Cのプログラム
3.プログラムの基本的なパターン
#include <stdio.h>
main( ) {
double fahrenheit; /* 華氏 */
double celsius;
/* 摂氏 */
scanf(“%f”, &fahrenheit);
celsius = ( fahrenheit – 32 )*5.0/9.0;
printf(“%f”, celsius);
}
5.構造化プログラミングと制御構造
順次
反復
S=S+1
X = f(S, 5)
S = g(X) + S
構造化プログラミング
分岐
5.構造化プログラミングと制御構造
• 順次
• 反復
– for文
– while文
– do-while文
• 分岐
–
–
–
–
goto文
break文
continue文
switch文 & case文
For文
• Syntax:
for(式1; 式2; 式3)
文
• 例:
for( i=1; i <= 100; i++)
s = s + i;
i=1
i<=100
s=s+i
i++
Flow Chart
今度は、…
• プログラミングの側面から
• 開発手法の側面から
ソフトウェアのライフサイクル(1)
1.
2.
3.
4.
5.
6.
要求分析
設計
プログラミング
デバッグ
評価
運用
⇒再び1へ戻る
ソフトウェアのライフサイクル(2)
1.
2.
3.
4.
5.
6.
何(どんなもの)を作ればいいの?
どう作ればいの?
作成作業そのもの(デバッグもやりながら)
本当にちゃんとできたのかな?
実際に使おう!
ちょっと変更したいな。
ソフトウェア開発モデル
•
•
•
•
•
•
•
ウォーターフォール(water fall)モデル
プロトタイピングによるソフトウェア開発
インクリメンタルモデルとイテラティブモデル
スパイラルモデル
データフローモデル
アジャイルモデル
モデル駆動型
=>一長一短あり
自主問題:
ウォーターフォールモデル , スパイラルモデルおよび
モデル駆動型アーキテクチャ(MDA)について調べよ。
ソフトウェア開発過程の確立
現時点では、経験的・
体験的にtry!
銀の弾丸はあるのだろうか?
問題
• 「銀の弾丸」とはソフトウェア工学の分野では
何を意味しているのでしょうか?調べてみてく
ださい。
銀の弾丸とは
• ソフトウェア開発の現場における諸問題に対
して、あまねく通用する万能解決策のこと。
• このような「万能な解決策(銀の弾丸)は存在
しない」という表現で、ソフトウェア開発の難し
さを表現することがある。
銀の弾丸はなくても…
• あきらめてはいけない!
– 1つの提案が「モデリング」とそれを記述・表現す
るための「モデル記述言語」である。
(以下、その話をしましょう)
今日の内容(再)
• 要求仕様を作ってみよう
• ソフトウェア開発過程の概要
• UMLの概説
• Javaプログラミング など
• 今日の課題(課題番号No2)
UMLの歴史
• (前回資料参照)
• とにかく、いいプログラムはいい設計が大切、
という観点から、さまざまな開発手法が考えら
れてきた。
それでわかったこと
• 要求仕様の明確化
• それにもとづくきちっとした設計
– プラットフォームに依存しない
「機能やサービス」のレベル
– プラットフォームに依存する
「実装」レベル
• 設計にきちんと基づく「実装」
• 要求仕様に対応した検証 が大切
• これらのレベルごとに、当該システムをモデ
ル化することが大切。
• その際、モデルを記述する表現(言語)が必
要。
=> UML の登場!
UMLはモデル記述のための言語(図で標記)
UML各種ダイアグラムの紹介
– ユースケース図
– クラス図
– その他のUML図
UMLとは
(ソフトウェア工学的観点から)
• UML(Unified Modeling Language)
– システム開発の分野で現在最も注目されている
ツール(仕様等の記述言語)の1つ。
– システムの構想をビジュアルに表現できる。
(visual language)
– 誰とでも誤解なく意思疎通できる。
(communication tool)
何を作るのかは、明確にし
ておかなければ…
UMLとは
(言語論的観点から)
• UMLは言語 の1つ
– 言語
• 音声言語 (Spoken Language):
– 所謂話し言葉
– 若者語 etc.
• 文字言語 (Written Language) :
– 書き言葉
– 法律文 etc.
• 視覚言語 (Visual Language):
– 手話 (sign language)
– ダイヤグラム(Flowchart, UML etc.) etc.
ちょっと雑談(1)
• 言語とは
– 思考のための道具
– 知識を記述し蓄えるための道具
– 意思疎通のための道具
上記のことを意識しておくことが大切!
ちょっと雑談(2)
• UMLとは
UMLも
1つの言語
– 思考のための道具
– 知識を記述し蓄えるための道具
– 意思疎通のための道具
通常はこの点のみが
強調されている
ちょっと雑談(3)
• Syntax v.s. Semantics
(統語論 v.s. 意味論)
• 表現形式 v.s. 意味内容
ちょっと雑談(4)
• Syntax v.s. Semantics
(統語論 v.s. 意味論)
• 表現形式 v.s. 意味内容
今日はこちらに
重点を置く
こちらの理解が
本質
参考情報
• 思考と言語について
– ヴィゴツキー:“思考と言語,” 柴田義松(訳),
新読書社(2001).
– 柴田義松:“ヴィゴツキー入門,”寺小屋新書(2006).
– 思考と言語研究会(電子情報通信学会)
( http://www.ieice.org/~tl/what.html )
12月に工科大で開催 (参加料無料)
• 意味への取り組みについて
– Semantic Web(http://www.w3.org/2001/sw/)
– Semantic Computing(http://www.instsec.org/)
– Web2.0
さて、…
UMLとは
• これから作ろうとしているシステム(ソフトウェ
ア)の概念をさまざまな側面から切り出し、表
現する図(ダイアグラム)群のこと。
作りたいと思っているもの
→ 概念
→ 仕様
→ 実装
完成したシステム(ソフトウェア)
UMLで使用する図(新)
ユースケース図
クラス図
オブジェクト図
シーケンス図
ステートマシン図
(ステートチャート図)
6. アクティビティ図
7. コンポーネント図
1.
2.
3.
4.
5.
8. コミュニケーション図
(コラボレーション図)
9. 配置図
10. コンポジット図
11. タイミング図
12. 相互作用概念図
順序と内容を確認すること!
ユースケース図
• 定義:
– システムの機能・要件(ユースケース)を
ユーザ等(アクター )の視点で示した図
– システムの使われ方(要求・機能)を記述するた
めの図
要件(ユースケース)やアクターを具体例で示す。
(参考)ユースケース
• ユースケースを図示する方法が
ユースケース図である。
• ユースケース(システム要求機能)の
記述方法は、場合によってはテキストでも
良い。
講義では飛ばしました。By KAMEDA
ユースケースの参考図書
・Alistair Cockburn: Writing Effective Use
Cases, Addison-Wesley, ISBN
0201702258 (2000)
・ユースケース実践ガイドー効果的なユース
ケースの書き方:アリスターコーバーン,翔泳
社, ISBN 4798101273(2001)
講義では飛ばしました。By KAMEDA
システムの具体例
• 例:
– 講習会予約システム
– 缶ジュースの自動販売機
– トランプゲーム(BlackJack)
– お風呂温度・水量設定システム
– スケジュール閲覧システム
– チャットシステム
講習会予約システム
講習会予約システム
• 申込みをしている風景
タンジブルソフトウェア入門
と人工知能特論コースを取
ろうかなぁ…
講習受講希望者
Model: Chiaki KUBOMURA 協力:山野美容芸術短期大学
講習会予約システム
• 事務処理をしている風景
タンジブルソフトウェアは
空いているけど、人工知
能特論はどうかなぁ…
受講登録事務員
Model: Chiaki KUBOMURA 協力:山野美容芸術短期大学
講習会予約システム
• 要件(要求される機能):
– 申込み
– キャンセル
– 領収書発行 など
• アクター:
– 受講者
– 経理担当
– 顧客管理システム
缶ジュースの自動販売機
• 要件:
– コイン投入待ち
– 金額計算
– 販売可能商品の表示
– 購入希望商品の選定
– 商品の出力
– 釣銭の出力
• アクター:
– 購入者
トランプゲーム(BlackJack)
• 要件:
– カードシャッフル
– カード要求
– 持ち札の把握
– 勝敗の判定
– 勝敗結果の表示
• アクター:
– プレイヤ
講習会予約システム(再)
• 要件(要求される機能):
– 申込み
– キャンセル
– 領収書発行 など
• アクター:
– 受講者
– 経理担当
– 顧客管理システム
講習会予約システム
ー ユースケース図 ー
講習会予約システム
ユースケース
アクター
システム境界
関連
ユースケース図の用語(1)
• アクター:
– システムと相互作用する
利用者や外部システムの役割
– ユースケースを駆動する。
– 人間(利用者)、外部システム、ハードウェア
Stickman とも言う
ユースケース図の用語(2)
• ユースケース:
– システムが提供する機能(振る舞い)
– アクターとシステムとの対話をモデル化
– ユースケースにより、システムの用途が網羅
ユース
ケース名
ユースケース図の用語(3)
• 関連:
– アクターとユースケースとの関係
– 関係があれば線で結ぶ
関連名
• システム境界:
– システムの外部と内部とを区別する。
内部
外部
トランプゲーム
ー ユースケース図 ー
(練習:各自で描いてみよう!)
• アクター:___
• ユースケース:___
クラス図
• とても重要な図です。
• 特に、programmerにとっては。
プログラマにとっては、
ソースコードの方が
もっと大切です。
クラス図
• 定義:
– システムの静的な構造を表したもの
– 問題領域やシステムの構造を、論理的・静的に
捉えるためのもの
クラス図の例
• 学生と学部
0..*
1
学生
-学生番号
-氏名
-住所
学部
- 学部名
-所在地
-電話番号
+学生情報取得()
+ 入学手続き
+ 休学手続き
+ 転学部手続き
クラス図の例
クラス名
• 学生と学部
関係
0..*
1
学生
学部
-学生番号
- 氏名
-氏名
-住所
-住所
-電話番号
属性
+学生情報取得()
+ 入学手続き
+ 休学手続き
+ 転学部手続き
操作
クラス図の例
クラス名
多重度
• 学生と学部
0..*
1
学生
学部
-学生番号
- 氏名
-氏名
-住所
-住所
-電話番号
属性
+学生情報取得()
+ 入学手続き
+ 休学手続き
+ 転学部手続き
操作
クラス図の用語(1)
• クラス:
– 具体物(インスタンス)を抽象化したもの
– 属性の操作(関数)をもつ
– インスタンスの設計図に相当
クラス名
属 性
操 作
クラス図の用語(1)
• クラス:
– 具体物(インスタンス)を抽象化したもの
– 属性と属性の操作(関数)をもつ
– インスタンスの設計図に相当
後で参照する
ためのもの
クラス名
属 性
操 作
属性のみ(属性値なし)
(属性に対する)関数
クラス図の用語(2)
•関係:クラス間の相互関係
クラスA
クラスB
関連
集約
汎化
依存
合成
クラス図の用語(3-1)
• 多重度:
– クラスから生成されるインスタンス(オブジェクト)
の個数などを表す。
N
M
クラス図の用語(3-2)
• 多重度の記述法:
n
1..
1..*
*
1,3,7
nのみ
1以上
1以上
任意の数
1か3か7
例: 3..*
3以上
通常は0や1が使われる
他の数字と組合わせて使用
離散値を扱う場合に使用
クラス図の例(再)
クラス名
多重度
• 学生と学部
多重度1
多重度0以上
0..*
1
学生
学部
-学生番号
- 氏名
-氏名
-住所
-住所
-電話番号
属性
+学生情報取得()
+ 入学手続き
+ 休学手続き
+ 転学部手続き
操作
練習問題
• (クラス図の作成)
クラスの例1
自動車クラス
is-a関係
Racing car is a car.
レーシング
カークラス
バスクラス
タクシークラス
自動車のクラス階層(1)
自動車
レーシングカー
バス
タクシー
自動車のクラス階層(2)
自動車
レーシングカー
バス
タクシー
例:自動車とその部品(1)
車 台
窓ガラス
ボディ
タイヤ
エンジン
ハンドル
例:自動車とその部品(2)
車 台
窓ガラス
ボディイ
タイヤ
エンジン
ハンドル
例:自動車とその部品(3)
自動車
車 台
ボディ
エンジン
例:自動車とその部品(4)
• 自動車のクラス階層
• 自動車とその部品
形式が同じに
なっている!!
これらを区別する方法は…
例:自動車のクラス階層
自動車
汎化
特化
レーシングカー
バス
タクシー
例:自動車とその部品(3)
自動車
車 台
ボディ
エンジン
合成の関係の場合
自動車
車 台
ボディ
エンジン
集約の関係の場合
家 族
お父さん
お母さん
子供
オブジェクト図
• 定義:
– クラス図に出てくるオブジェクトの相互関係を示し
たもの
– 静的構造を把握
オブジェクト図の例
クラス図
学部
学生
オブジェクト図
:学部
:学生
CS
鈴木
:学生
佐藤
:学生
田中
オブジェクト図の例
クラス図
学部
学生
オブジェクト図
:学部
:学生
CS
鈴木
オブジェクト名
:学生
リンク
佐藤
:学生
田中
値
シーケンス図
• 定義:
– オブジェクト相互の協調またはメッセージを、時間
軸に着目して表示する図
シーケンス図の例
:obj1
:obj2
コミュニケーション図
• 定義:
– オブジェクト間のメッセージのやり取りを、接続関
係に着目して記す図
– シーケンス図とほぼ同じ内容となる。
着目点が異なる。
コミュニケーション図の例
1:番号入力
3:実行
2:確認ランプ
:obj01
:検索コント
ローラ
4:結果画面表示
5:結果表示
検索結果画面
ステートマシン図
• 定義:
– オブジェクトの状態の変化や、その変化が起きる
ための条件を表す図
ステートマシン図の例
• ジュースの自動販売機
待機中
コイン投入
キャンセル
商品選択
[120円以上]
コイン投入中
[120円未満]
コイン投入
購入可
ジュース
販売
アクティビティ図
• 定義:
– システムの動的側面をフローチャートの要領で表
現する図。
(並行処理を表現することができる。)
アクティビティ図の例
アクター1
アクター2
その他の図
• コンポーネント図:
– ソースファイルなど、システム開発に必要なコン
ポーネントとそれらの依存関係を表現する図
• 配置図:
– システムを実行するハードウェアの配置やそれら
の相互接続関係を表現する図
UMLで使う図(再)
1.
2.
3.
4.
5.
6.
7.
8.
ユースケース図
クラス図
オブジェクト図
シーケンス図
ステートマシン図(ステートチャート)
アクティビティ図
コミュニケーション図
配置図 etc.
UMLでの5つのビュー(1)
• システム開発を成功させるためには、開発す
るシステムを多様な視点(ビュー)から眺める
ことが大切。
UMLでの5つのビュー(2)
•
•
•
•
•
ユースケースビュー
論理ビュー
並行性ビュー
コンポーネントビュー
配置ビュー
UMLでの各種ビュー(3)
論理ビュー
ユースケースビュー
クラス図
オブジェクト図
シーケンス図
ユースケース図
アクティビティ図
ステートマシン図
(ステートチャート)
コミュニケーション図
(コラボレーション図)
コンポーネント図
配置図
コンポーネントビュー
並行性ビュー
配置ビュー
UMLでの5つのビュー(4)
1. ユースケースビュー: アクタの視点からシステム
の機能を見る視点
2. 論理ビュー: システムの論理的構造をみる視点
(ビジネスロジックなど)
3. 並行性ビュー: 処理の同期・非同期に着目する
視点
4. コンポーネントビュー:開発者のビュー。ソフトウェ
アコンポーネントの依存関係を見るビュー。
5. 配置ビュー: 物理的配置を見るためのビュー
UMLでの各種ビュー(3)
論理ビュー
ユースケースビュー
クラス図
オブジェクト図
ユースケース図
アクティビティ図
シーケンス図
状態図
コラボレーション図
コンポーネント図
配置図
コンポーネントビュー
並行性ビュー
配置ビュー
ここまでのまとめ
• ソフトウェア開発は大変だ。いいプログラムな
んかなかなかできない。でも、仕様をしっかり
決めたり、きちんとした設計をすることは大切
だよね。その一助としてモデリング言語
(UML)を用いてモデル化をしっかりやろう。
(上流工程は重要だ!)
• UMLの各ダイアグラムの使い方は、システム
開発を実践しながら覚えていきましょう。
(UMLの話はまずはここまで。)
次は、…
• ちょっと話を変えて…
今日の内容(再)
• 要求仕様を作ってみよう
• ソフトウェア開発過程の概要
• UMLの概説
• Javaプログラミング など
• 今日の課題(課題番号No2)
最後にはシステム(プログラム)を
作らなければ面白くないので、
少しJavaの話をします。
Javaプログラムの例
import javax.swing.JFrame;
public class SimpleFrame extends JFrame{
public SimpleFrame(){
super(“Frame Title”);
setSize(300,100);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setVisible(true);
}
public static void main(String[] arguments){
SimpleFrame sf = new SimpleFrame();
}
}
練習問題
• 前述のプログラムを実際に実行してみなさい。
今日の内容(再)
• 要求仕様を作ってみよう
• ソフトウェア開発過程の概要
• UMLの概説
• Javaプログラミング など
• 今日の課題(課題番号No2)
次回までの課題
レポートではない課題1
• 先ほどのJavaのプログラムを実際に実行さ
せて見なさい。必要ならば、Javaの開発環境
を整備しておくこと。
(JavacコマンドやJavaコマンドが使えれば
OK。エディターも必要ならばそろえておいてく
ださい。)
レポートではない課題2
• 教科書の
– 図1-1-3
– 図1-1-10
– 図1-1-18
– 図1-1-21
の4つの図が読めるように、練習してください。
(図に描かれていることを口頭で説明できれ
ばOKです。)
レポート課題No.2
•
大学の掲示版として、「個人専用の掲示板」
を作るとしたらどんなものがいいのかを考え、
以下の3点に関して文書化しなさい。
1. 表示画面のデザイン(外見のデザイン)
2. 提供する情報・サービス(情報デザイン)
3. サービスの利用形態(誰がいつ何をどのように等)
仲間と相談
してもいい
よ。
これは次回提出してもらいます。
次回の予告
• 次回からソフトウェア開発に取り掛かります。
• UML関連のツール(JudeとEclipse)の話を
します。 「弘法は筆を選ばず」といいますが、
IT技術者とりわけプロフェッショナルIT技術者
にとっては、ツール(tool,道具)は重要です。
具体的なツールの話をしますので、欠席をす
ると損をしますよ…
• PCとネットワークケーブルを持参してください。
それではまた次週!
All is over.
提出してください
レポート課題No1
• 教科書の8ページから40ページまでを読ん
で、専門用語と思われる用語を抽出し以下の
ように分類しなさい。
– [手順0] A4の紙を3枚用意し、各用紙の右上に
○、△、×の印を大きめに書く。
– [手順1] 教科書の8~40ページを順に読む。
– [手順2] 専門用語を見つけ、もし知っている用語
ならば○の紙に、知らない用語ならば×の紙に、
それ以外は△の紙に、それぞれ順次書き込む。
– [手順3] 集まったらコピーをとり、表紙を付けて次
回授業時に提出する。原本は手元に保存してお
くこと。