Embed Size (px)
Citation preview
プログラミング実践II
ソフトウェア工学ソフトウェア構成管理とGitの使い方テスティングフレームワークライブラリドキュメントの読み方
担当：今井
岐阜大学工学部電気電子・情報工学科 情報コース
プログラミング実践II (平成30年度)
1V1.1
GitHubアカウントを作ってください
GitHub https://github.com/ でアカウントを作ってください
アカウント作成後、
https://classroom.github.com/a/yDO-poxO
にアクセスしてください
1. 自分のログイン IDを選択してください。
– 決して Skip をクリックしないでください。
2. Invitation を accept してください。
何か間違えたり、自分のログイン IDが見当たらない場合は 今井まで
2
この講義では
ソフトウェア工学のうち、ソフトウェア開発プロセスの概論的な紹介
– どういう仕事をしたいかの指針にもなるかもしれません
ソフトウェア構成管理と Git の使い方
ライブラリドキュメントの読み方
ソフトウェアテスト
– Android におけるテスト
3
ソフトウェア工学
ソフトウェア開発プロジェクトを成功させるのは容易でない
– 「成功」の指標： 品質・コスト・納期
ソフトウェア特有の「難しさ」
– ソフトウェア要求の難しさ： 取り巻く環境の人類学・社会学的な複雑さ
（他の人工物と比べて、要求の変化の振れ幅が大きい）
– ソフトウェア構築の難しさ： 要素技術の習得の難しさ、仕様と実物の整合性の維持、
開発者の認知的能力の限界、計算の理論的な限界
– プロジェクト運営の難しさ：
上記 2つ＋複数人による合意形成やスケジュール管理の難しさ
4
ソフトウェアを、実社会の制約の中で開発・運用・メンテナンスするための体系
（必ずしも理論や原理の裏付けがなくても、経験的に良いものは取り入れる 「工学」）
ソフトウェア開発プロセス
5
要求分析
• 何をやりたいか・そのためにソフトウェアで何ができるかを分析する
• 要件を定義する
設計
• ソフトウェア全体の仕様を決める （外部設計）
• 各クラス（モジュール）の仕様を決める（内部設計・詳細設計）
• 要素技術（ライブラリやフレームワーク、アルゴリズム）を選定する
実装• 各クラス（モジュール）のプログラムを書く
単体テスト• 各クラスが仕様通り動作することを確かめる
システムテスト
• 全体として仕様通りに動作することを確認する
• 要件を満たしていることを確認する
リリース
• 受け入れテスト
• 本番環境にソフトウェアを配備（deploy：Webアプリケーションをサーバーにアップロードして動作状態にすること）
• マニュアルを作る、納品する
特に、この順序で実施するソフトウェア開発プロセスのことをウォーターフォールモデルと呼ぶ（リリースはプロジェクトの形態や契約（受託、自社開発）、ソフトウェアの稼働環境（Webサービス、モバイル、PC）等によって異なる）
ソフトウェア開発プロセス
6
要求分析
• 何をやりたいか・そのためにソフトウェアで何ができるかを分析する
• 要件を定義する
設計
• ソフトウェア全体の仕様を決める （外部設計）
• 各モジュール(クラス)の仕様を決める（内部設計・詳細設計）
• 要素技術（ライブラリやフレームワーク、アルゴリズム）を選定する
実装• 各クラスのプログラムを書く
単体テスト• 各クラスが仕様通り動作することを確かめる
システムテスト
• 全体として仕様通りに動作することを確認する
• 要件を満たしていることを確認する
リリース
• 本番環境にソフトウェアを配備（deploy）する
• マニュアルを作る、納品する
これらのプロセスは業態や開発現場によって著しく異なる（次頁以降で検討）
現実には工程を厳密に区別しないことが多い
– とはいえ受託開発等で、①仕様を決めて②実装して③納品する、というモデルは典型的
– 現実には仕様変更や手戻りがある。
より柔軟な開発プロセス：「反復型開発」 特に自社開発で利用可能
– スパイラルモデル、アジャイルソフトウェア開発モデル等
開発プロセスには一方向性、不可逆性がある
– プロジェクトには予算と納期があり、工数の見積もりが早期段階で必要
– 経験的事実：「発見済み欠陥の数はプロジェクト後期になれば収束していく」（まともなプロジェクトならば）
「リリース直前に実装を修正するのはコストが高い」
– 修正しやすさ（保守性）を考慮したアーキテクチャ設計は早期段階に決める必要がある
工程を意識する： 「木を見て森を見ず」を避けるために、目的と手段を区別
– 要件と仕様を区別 （仕様は顧客の目的を達成するか？仕様書に抜け・漏れがないか？）
– 仕様と実装を区別 （要素技術に捕らわれていないか？もっと簡単にできないか？）
特に、この順序で実施するソフトウェア開発プロセスのことをウォーターフォールモデルと呼ぶ（リリースはプロジェクトの形態や契約（受託、自社開発）、ソフトウェアの稼働環境（Webサービス、モバイル、PC）等によって異なる）
顧客の視点で：ソフトウェア調達の2つの軸 (Software Acquisition: ソフトウェア調達/獲得)
7
• 調達方法
– 新規開発 （Custom）： 要求分析・設計・実装から導入までをゼロから実施
– 既存サービス・パッケージ導入 (Package)： 既存のソフトウェアやサービスをそのまま使う
• 調達チーム
– 自社で (Insource)： 賃金その他のリソースを準備し、従業員が主な労働を担う
– 外注で (Outsource)： 他社に発注し、金銭を支払う
現実にはそれぞれの中間もあり得る• パッケージを調達して大きく改修する• 自社で要求分析し他社が設計・実装する
ソフトウェアの調達・入手の経済的観点
(P. Nelson et al., CACM, ’96 より)
顧客の視点で：ソフトウェア調達の2つの軸 (Software Acquisition: ソフトウェア調達/獲得)
調達チーム (Acquisition Team)
調達方法
(Acq
uisitio
n A
pp
roach
)
自社で (Insource) 外注で (Outsource)
新規開発
(Cu
stom
/ Besp
oke)
例： Web系企業の自社開発
要求把握やコミュニケーションのコスト低
技術者の雇用維持のコスト（人件費）
（日本は終身雇用が基本）
例：社内システムをSIerに外注
契約、要求把握と仕様策定のコスト高
初期投資高（数百万～数億）＋メンテナンス費
サービス・
パッケージ導入
例：アプリストアからのDL, 有償クラウド
サービスの利用，代理店からの購入
社内の情報システム部門が担当
例：岐阜大のAIMS (LMS というオープン
ソースソフトウェアを改修)
比較的小規模な OSS 導入(Wordpress)から大規模ERPパッ
ケージの全社的導入まで
当該組織にとって技術的難度が高い場合、保守
人員を割けない場合
要件の伝達とカスタマイズが鍵8
開発者の立場：ソフトウェアプロジェクトの発生要因とユーザー
依頼主は？
– 他社からの依頼：
コミュニケーション、契約履行、説明責任のためのコストがかかる
要求や仕様を文書化し、成果物を厳密に定義する必要があることも
⇒ ウォーターフォール的。「システムエンジニア」「SIer」の活躍の場
– 自社が依頼主である：
柔軟な開発。より反復的なプロセスで開発でき、変化に柔軟に対応できる
より技術指向かつプログラマ主体な開発も可能
エンドユーザーは？
– 依頼主が使用 （いわゆる受託開発や社内向けサービス）：
要求獲得が相対的に容易で、オーダーメイドが可能。スケール固定
– 一般向け（パッケージやサービス開発）：
要求が必ずしも明確でない。スケーラビリティの考慮が必要
9
開発会社の立場で考えると：
開発者の立場：ソフトウェアプロジェクトの発生要因とユーザー
10
依頼主
エンドユーザー
自社が依頼主 （自社開発） 他社が依頼主 (いわゆる受託開発)
依頼主が使用
〇自由度高、コミュニケーションコスト低
〇要求分析が相対的に容易
△技術者の雇用維持のコスト（人件費）
△スケールはしない
〇契約が完了すれば売り上げを確定しやすい
△コミュニケーションのコスト
（仕様の厳密化、プロジェクト管理コストの増大、
説明責任）
一般向け
〇自由度高、コミュニケーションコスト低
△要求把握のコスト
△技術者の雇用維持のコスト（人件費）
〇大きくスケールする可能性がある
（スケーラビリティが必要）
〇契約が完了すれば売り上げを確定しやすい
△依頼主とのコミュニケ―ションコスト
マーケット知識の大きな不足
いわゆる「受託開発」
自社サービスの開発、パッケージ製品
余談：ある社長曰く、日本国内では
11
https://jp.quora.com/なぜ日本では-ソフトウェア開発者の地位が低い-例え/answers/58957077
余談：ある社長曰く、日本国内では
12
https://jp.quora.com/なぜ日本では-ソフトウェア開発者の地位が低い-例え/answers/58957077
“インターネット革命以降、ソフトウェアは単なる効率化の道具でなく、事業にとって欠かすことの出来ない本質的な存在となってきていますので、この状況は日本でも変わってきています。
とくにインターネット企業では、ソフトウェア開発者の待遇は大幅に改善されているので、そういう会社に入ることができる開発者にとっては日本の待遇が悪いとは言えなくなっています。…”
ソフトウェア工学基礎知識体系 (SWEBOK; Software Engineering Body of Knowledge)
第1章 ソフトウェア要求
第2章 ソフトウェア設計
第3章 ソフトウェア構築
第4章 ソフトウェアテスティング
第5章 ソフトウェア保守
第6章 ソフトウェア構成管理
第7章 ソフトウェアエンジアリング・マネジメント
第8章 ソフトウェアエンジアリングプロセス
第9章 ソフトウェアエンジニアリングモデルおよび方法
第10章 ソフトウェア品質
第11章 ソフトウェアエンジニアリング専門技術者実践規律
第12章 ソフトウェアエンジニアリング経済学
第13章 計算基礎
第14章 数学基礎
第15章 エンジニアリング基礎
13
ソフトウェア工学に関連するトピックのサマリと参考文献集 (IEEE, 2013)
IEEE よりダウンロード可能https://www.computer.org/web/swebok/v3日本語版は (訳に難があるが)
https://www.amazon.co.jp/dp/4274505219あるいは Google Play に電子版あり
チームによるソフトウェア開発を「より良くしたい」時に検討する。ただし、教科書の多くはやや抽象的に書かれており愚直に従うのではなく「現実に落とし込む」ステップが重要
ソフトウェア工学の教科書と現実
今井の手元にある書籍
– 岸，野田 「ソフトウェア工学」 近代科学社, 2016.
– 平山，鵜林 「ソフトウェア工学 (IT Textシリーズ)」 オーム社, 2017.
– 高橋, 丸山 「ソフトウェア工学 (情報工学レクチャーシリーズ)」 森北出版,
2010.
上記のアカデミックな方法論以外に、インターネットの発展・開発技術の
進展につれて様々なツールや方法論が次々と生まれている
– 抽象的すぎる 「ソフトウェア工学」 を現実が追い抜いていく
– 「DevOps」「継続的インテグレーション」等、具体的な方法論＋ツールが世を席捲する時代
– 書籍だけでなく、インターネット上での情報収集も必要
要望があれば今後の今井担当回で扱います
14
Gitによるソースコードバージョン管理と構成管理
15
Git for Windows: 準備
端末で Git Bash を起動してください。 Git for Windows を使うためのシェルが起動します。
– 左下の⊞ボタンクリック → Git と入力すれば出てきます
– 適宜ウィンドウを大きくしてください
次のコマンドを実行してください
16
git config --global core.editor "notepad" # コミットメッセージのエディタを メモ帳にgit config --global color.ui true # 文字に色を付けるgit config --global http.proxy proxy.eng.gifu-u.local:10080 # プロキシの設定git config --global https.proxy proxy.eng.gifu-u.local:10080 # プロキシの設定git config --global core.askpass '' # パスワードを Git Bash 経由で入力git config --global credential.helper '' # Gitのパスワードマネージャを無効に (使えません)
git config --global user.email "あなたのeメールアドレス" # 大学のメールアドレスgit config --global user.name "あなたの名前" # "Hanako Yamada" など
計算機室固有の設定： AIMS ↓からコピペしてください (PDFからのコピーは不可)
https://aims2.gifu-u.ac.jp/courses/17786/discussion_topics/4296：
あなた固有の設定：
コマンドラインインタフェース (CUI) を使おう / Unix のエコシステムは重要です
例： 殆どの Web系企業は Unix 系の開発環境を採用している
– 代替は Microsoft 系ですが近年の MS は Unix 文化を強力に取り込んでいます
例： WSL (Windows Subsystem for Linuxなど)
開発環境は、 GUI よりも CUI のほうが望ましいケースが多い
– 動作が明快
– 詳細なコントロールが可能
– 複数のツールをシェル機能 (パイプ等) で容易に連動させられる
– 自動化できる
– どのみちサーバー管理で使う
Unix 系のツールである Git を使うため、 Git Bash を使ってもらいます
– Windows は cmd.exe や PowerShell といった CUI 環境がありますが・・・
17
おさらい： シェル
「Git Bash」を起動すると 、入力待ちの状態になる
$
こうしたプログラムを「シェル」と呼ぶ. シェルは次のものが有名
– csh (シーシェル), tcsh (ティーシーシェル)
– sh, bash (バッシュ), zsh (ゼットシェル), fish
– Windows では cmd.exe や PowerShell
PC室の Linux 環境では csh がデフォルト
– "bash" とタイプすれば bash が起動します
18
シェルのコマンド①
シェルは、他のプログラムを起動するためのソフトウェア
– コマンドラインの最初の単語は呼び出すプログラムのファイル名を表す（外部コマンド）
– 上の例は、コマンド /bin/ls (ファイルのリストを表示するコマンド) を、 "/usr" というパラ
メータで呼び出す
外部コマンドはフルパスや相対パス（注）で指定しても良い
19
$ ls /usrプログラムのファイル名 引数（パラメータ）
$ /bin/lsフルパス ( / で始まり、ファイルを一意に特定可能)
$ ../bin/ls相対パス ( .. は「一つ上のディレクトリ」)
シェルのコマンド②
シェルのプロンプトと入力
– 現在のディレクトリの ~ は、「ホームディレクトリ」の短縮版
• 講義室のPCでは /z/ (C:¥)
• （プロンプトはカスタマイズできる（他のシステムでは異なるプロンプトかもしれない））
現在のディレクトリを表示するコマンド： pwd
– 試してみましょう
20
[GUEDU+w3033xxxx@pc202 ~] $ git config …
プロンプト（入力待ち状態を表す文字列）
ユーザーID(Windows環境下なので少し特殊)
ホスト名 現在のディレクトリ
コマンドライン
[w3033xxxx@pc202 ~] $ pwd/z/
シェルのコマンド③
内部コマンド
– シェルの状態を変化させる（注）様々なコマンド
– echo, cd, pwd, export, fg, bg, jobs, … 等
– cd コマンド： ディレクトリを移動する (現在のディレクトリを変更する)
– (備考) 内部コマンドは外部コマンドより優先される
（同じ名前の外部コマンドがあっても内部コマンドが呼び出される）
21
[w3033xxxx@pc202 ~] $ cd /tmp
シェルの変数
シェルは（ごく単純化された）プログラミング言語でもある
– 変数（環境変数）を定義し、参照できる
PATH 環境変数
– 外部コマンドの配置場所を表す特殊な環境変数
– コマンドの探索先をコロン(:)区切りで設定する
– 外部コマンド名を入力すると、PATHで指定したパスを順に探す
（/bin に「パスが通っている」という）
22
$ A=100 ← A という変数に "100" を代入
$ echo $A ← 変数 A の内容を表示
100$ expr $A + 1 ← 外部コマンド expr で、式を計算する
101
$ echo $PATH/usr/local/bin:/bin:/usr/bin
Git Bash 環境の PATH:
/z//bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/z/bin:/c/ProgramDat
a/Anaconda3:/c/ProgramData/Anaconda3/Library/mingw-
w64/bin:/c/ProgramData/Anaconda3/Library/usr/bin:/c/ProgramData/Anaconda3/Library/b
in:/c/ProgramData/Anaconda3/Scripts:/c/Program Files/Python36/Scripts:/c/Program
Files/Python36:/c/Program Files/Microsoft MPI/Bin:/c/Ruby25-x64/bin:/c/Program Files
(x86)/NVIDIA Corporation/PhysX/Common:/c/Program Files
(x86)/PerkinElmerInformatics/ChemOffice2016/ChemScript/Lib:/c/ProgramData/Oracle/J
ava/javapath:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Window
s/System32/WindowsPowerShell/v1.0:/c/Program Files/Microsoft SQL Server/Client
SDK/ODBC/110/Tools/Binn:/c/Program Files (x86)/Microsoft SQL
Server/120/Tools/Binn:/c/Program Files/Microsoft SQL Server/120/Tools/Binn:/c/Program
Files/Microsoft SQL Server/120/DTS/Binn:/c/Program Files (x86)/Windows
Kits/8.1/Windows Performance Toolkit:/cmd:/c/Program
Files/MATLAB/R2018a/bin:/c/Program
Files/dotnet:/c/SIMULIA/Abaqus/Commands:/c/opencv/build/x64/vc14/bin:/c/borland/bcc5
5/Bin:/c/Users/keigoi/AppData/Local/Microsoft/WindowsApps:/usr/bin/vendor_perl:/usr/bin
/core_perl:/z//bin
23
このなかのどこかに git.exe がある
コマンド
基本的なコマンド (抜粋)
24
ls ファイル一覧 mkdir, rmdir ディレクトリを作成, 削除
cat,less
ファイルの内容を表示 id 現在のユーザを表示
rm ファイルを削除する passwd パスワードを変更
cp ファイルをコピーする su ユーザーを切り替える
chmod ファイルの属性を変更 man マニュアルを見る
chown ファイルの所有者を変更 gzip, gunzip ファイルを圧縮/展開
ln ファイルやディレクトリへのリンクを作る tar 複数のファイルをアーカイブする(一つにまとめる)
Bash の内部コマンド (抜粋)
cd カレントディレクトリを変更 export 環境変数のエクスポート
pwd 現在のディレクトリを表示 alias 短縮コマンドの作成
echo 文字列を表示
history コマンドの入力履歴を表示
fg, bg ジョブの切り替え
jobs ジョブ一覧
Unix のファイルシステム
Unix のファイルシステムは単一のルート（根）をもつ木構造である
– シェルはカレントディレクトリ（現在のディレクトリ）をもつ
– cd コマンドで移動でき、 pwdコマンドで現在位置を確認できる
25
/ ルートディレクトリbin/ 基本的なコマンド群dev/ デバイスファイル等etc/ 設定ファイル
X11/cron.d/…
home/ ホームディレクトリstaff/students/w3033xxx/…
sbin/tmp/ 一時ファイル用usr/
bin/ 一般のコマンド群…
var/log/ ログファイル…
cd /tmp
$ pwd/home/students/w3033xxx$ cd /tmp$ pwd/tmp$ cd ← パラメータ無しの cd でホームディレクトリに戻る
$ pwd/home/students/w3033xxx
（備考） Windows のファイルシステムは 複数のドラ
イブを根として持つ
– 根： C:¥, D:¥, Z:¥, …
– ディレクトリ： C:¥Windows, …
Bash の代表的なキーバインド
コマンドを効率よく入力しましょう
26
キーバインド 機能
Ctrl-N, Ctrl-P コマンド履歴を一つ次へ(Next), 一つ前へ(Prev)
Ctrl-F, Ctrl-B カーソルを一文字前へ(Forward), 一文字後ろへ (Back)
Alt-F, Alt-B カーソルを1単語前へ, 1単語後ろへ
Ctrl-A, Ctrl-E カーソルを行頭へ, 行末へ
TAB 途中まで入力したファイル名の補完（おすすめ）
Ctrl-K 行末までカット
Ctrl-Y ペースト
Ctrl-R 以前に入力したコマンドの検索モードに入る（おすすめ）
Ctrl-G キャンセル(何か変なことになったら Ctrl-G を連打すると抜けられるはず)
Ctrl-L 画面のクリア
MinGW (Bash) のファイルシステム
/z/ など、ドライブ名がマップされている
/bin, /usr 等は C:¥Program Files¥Git¥bin あたりにあるはず
27
ソースコードのバージョン管理：動機
複数人で並行して開発したい
試作機能を実装したい（例： GPS 機能を加えたい）が、
元のソースコードは取っておきたい
ファイルをバックアップしたり、以前のバージョンに戻したい
– 欠陥が判明したので、原因を過去にさかのぼって追跡したい
– 仕様変更により切り戻しが必要になった
– ファイルが壊れた
ソフトウェアの構成管理
– 開発バージョンとリリースバージョン
– 古いバージョンと新しいバージョン
28
バージョン管理システム (Version Control System, 以下 VCS)
バージョン管理システム
– SCM (Source Code Management) システムとも
ソースコードの変更履歴を蓄積
著名なVCS： Subversion (SVN), Git, Mercurial など
蓄積する場所：リポジトリ
29
Git (ギット)
Git: 分散バージョン管理システム (Distributed VCS)
– 「分散」については後ほど解説
現在のオープンソース開発の主流
30
Git の基本： ① 空のリポジトリの作成
git init コマンドで myproject というリポジトリを作成し、そこに cd せよ
– .git というディレクトリがある。 "." で始まるファイル名はデフォルト不可視なので、
ls -a などのコマンドで確認する。
git status コマンドで、リポジトリの状態を確認せよ。
31
$ git init myproject # myproject ディレクトリが作成されるInitialized empty Git repository in /z/myproject/.git/
$ cd myproject
$ git status
# On branch master## Initial commit#nothing to commit (create/copy files and use "git add" to track)
← （後述）このワーキングコピーのブランチは master
← リポジトリは空で、次のコミットが初回コミットになるという意味
↑ ディレクトリに何も変更がなく、コミットすべきものがないという意味
Git： リポジトリへのファイル追加の流れ
ディレクトリにファイルを置いただけでは、リポジトリに追加したことにはならない
リポジトリにファイルを追加する「コミット」という操作が必要
リポジトリにファイルを追加するには、一旦「ステージ」にコピーしなければならない
コミットの度にステージを経由するのは煩雑であるが、便利な場合もある
– どのファイルをコミットし、どれをコミットしないかを git add で選択できる
– マージのコンフリクト（衝突; 後述）の解消の時にも使います
32
リポジトリ
ステージ（インデックス）
git add git commit
ステージにコピー リポジトリにコミット
ファイル
(次のステップのための準備)
myproject ディレクトリに README.txt という名前のプレーンテキストのファイル
を配置せよ。 内容は1~2行とし、エディタは何でもよい。
例） echo コマンドを使う場合：
33
$ echo "This is a project for git exercise." > README.txt
$ git status
# On branch master## Initial commit## Untracked files:# (use "git add <file>..." to include in what will be committed)##README.txtnothing added to commit but untracked files present (use "git add" to track)
← Git が追跡していないファイルが存在しますよ、という意味
↑ ステージに追加する方法の案内
← README.txt があるが、まだ リポジトリには入っていない
Git の基本： ② ファイルのステージング
git add コマンドで、ファイルをステージにコピーせよ
– git add は何度実行してもよい。 複数のファイルをステージにコピーできる。
– 同名のファイルを複数回 add すると、ステージ上にある以前のファイルは上書きされる。
git status コマンドで、リポジトリの状態を確認せよ
34
$ git add README.txt # README.txt がステージにコピーされる
$ git status
# On branch master## Initial commit## Changes to be committed:# (use "git rm --cached <file>..." to unstage)##new file: README.txt#
← ステージにファイル（コミットすべき差分）が存在する
Changes to be commited
← README.txt がステージに置かれた
↑ ステージから削除する方法の案内
Git の基本： ③ コミット
git commit コマンドで、ステージのファイルをリポジトリに追加（コミット）せよ
– コミットの説明書き（コミットメッセージ）を必ず残す。
（初回コミットのメッセージは Initial commit とすることが多い）
– チーム開発ではコミットメッセージが必須。 課題管理システムの課題ID（バグID）を書くことも多い。
何をしたかをそのまま書くのではなく、ファイル追加/修正の目的と、内容の補足を書くと良い。
35
$ git commit # エディタが起動するので、メッセージを入力して保存、閉じるもしくは
$ git commit -m "Initial commit" # -m オプションでメッセージを直接指定できる
[master (root-commit) 0248e2a] README.txt1 file changed, 1 insertion(+)
create mode 100644 README.txt
このコミットを表す の上７桁ハッシュ値応答
↓コミットしたブランチ（後述）
Git の基本： ④ ファイルの上書き
(準備) README.txt に新しい行を追加し、保存せよ。以下は例：
変更をリポジトリにコミットせよ。
36
$ git add README.txt$ git commit -m "Date added" ← コミットメッセージ
$ notepad README.txtThis is a project for git exercise.このプロジェクトは5月24日に始まりました。(↑追加行)
README.txt の編集例
Git の基本： ⑤ コミットログ（変更履歴）の参照
git log コマンドで、 コミットログを確認せよ
最初のコミットの値（↑の 0248…）をコピーせよ (次頁で使います)。
37
$ git log
commit 2915339cfc47dfb23db674cb2c5ddec485eb1260Author: Keigo IMAI <[email protected]>Date: Wed May 17 10:47:54 2017 +0900
Date added
commit 0248e2a3bdcfcef46852a579c391333419208589Author: Keigo IMAI <[email protected]>Date: Wed May 17 10:30:28 2017 +0900
Initial commit
最初のコミットを表す ハッシュ値
二番目のコミットを表す ハッシュ値
コミットした人
コミットした日時コミットメッセージ
Git の基本： ⑥ ファイルの巻き戻し
git checkout コマンドで、 最初にコミットした時のプロジェクトをリポジトリから
取り出せ (チェックアウト)
(⇒ detached HEAD 状態に関するメッセージが表示されます（後述）)
– 以前リポジトリにコミットした README.txt が復活する。
– 注意： checkout コマンドは元あったファイル（ワーキングコピー）を上書きしてしまう。
時には作業内容が消えるかもしれないため注意すること。
元の状態に戻すには、次のようにする（詳細は後述）
38
$ git checkout 0248e2a3bdcfcef46852a579c391333419208589 ↑前頁の Initial commit のハッシュ値（人によって異なります）
もしくは
$ git checkout 0248e2a （最初の数桁でも可）
$ git checkout master
Git の基本： ここまでのまとめ
39
└ .git
└ README.txt
└ main.c
└ lib
└ a.h
└ b.h
└ test1.c
└ test2.c
myproject
リポジトリの実体 (ステージもここに格納される)
ワーキングコピー（ワークツリー）
リポジトリのディレクトリ構造
リポジトリ
ステージ（インデックス）ワーキング
コピー（ワークツリー）
git add git commit
git log
git checkout
コミットまでの流れ
ステージにコピー リポジトリにコミット
コミットの履歴を見る
git status: ワーキングコピーやステージの状態を調べる
より詳細な変更履歴
git log -p コマンドで、各コミットの詳細な diff を確認せよ
– 追加された行の頭には + (プラス) 記号が、削除された行には – (マイナス)記号が
表示される。
– このような差分の表示法は Unified Diff 形式 と呼ばれる、標準的な diff の一種である。
(Unix の patch コマンドや diff コマンドでも使う)
40
$ git log -p
Git のコミットツリー
Git のコミットはある時点のスナップショットである。
– 過去のプロジェクトの状態を再現でき、エラー（不具合）が見つかった時の原因の分析に役
立つ
– コミットログは、コミット頻度などプロジェクトの統計を取るのにも役立つ
コミットにはブランチ (枝)という名前をつけることができる
– デフォルトのブランチには master という名前がついている
Git のディレクトリ（ワーキングコピー）は、「現在のコミット」「現在のブランチ」を追跡し
ている
– git status コマンドで、現在のワーキングコピーがどのブランチかを確認できる
– 現在のコミットを HEAD と呼ぶ (小文字の head とは異なるので注意)
41
0248e2a 2915339
最初のコミットmaster
＜イマココ！
ブランチ$ git status
# On branch masternothing to commit (working directory clean)
コミット
コミット詳解
コミットすると、ブランチは新しいコミットを指す。
42
0248e2a 2915339
master
＜イマココ！
0248e2a 2915339
master
＜イマココ！
3a44b81
$ git commit
[master 3a44b81] 1 file changed …
Git のコミットツリー
コミットは一般に有向グラフ構造になる。
– 分岐： あるコミットに対して追加機能を作りたい時に役立つ
– 合流： 追加機能を本家に取り込む（マージ；後述）
43
0248e2a 2915339 3a44b81 1de43a1
8a123b1
過去 未来
3b1441a
最初のコミット
Git の基本： ⑦ ブランチを切る
（準備）git log で最初のコミットのハッシュ値を調べよ
git branch で、最初のコミットに新しいブランチ test を作り、チェックアウトせよ
44
0248e2a 2915339
master
$ git log
…commit 0248e2a3bdcfcef46852a579c391333419208589 （人によって違います）Author: Keigo IMAI <[email protected]>Date: Wed May 17 10:30:28 2017 +0900
Initial commit
$ git branch test 0248e2a3bdcfcef46852a579c391333419208589$ git checkout test （上の git log で調べたハッシュ値）
test
＜イマココ！
0248e2a 2915339
mastertest
＜イマココ！
git branch 後 git checkout 後
(準備) test ブランチに、次の内容のファイル main.c をコミットせよ
45
int main(int argc, char** argv) {for(int i=0; i<10; i++) printf("Hello, World!¥n");
}
$ gedit main.c$ git add main.c$ git commit
0248e2a 2915339
master
test
f2324b0
＜イマココ！
[test f2324b0] 1 file changed …
myproject
└ README.txt
└ main.c
testブランチ の内容
Git の基本： ⑧ マージ
master ブランチをチェックアウトせよ
git merge コマンドで、 test ブランチを master ブランチにマージせよ
46
$ git checkout master
$ git merge test
0248e2a 2915339
master
test
f2324b0
＜イマココ！
0248e2a 2915339
master
test
f2324b0
＜イマココ！
2915339
コミットグラフの確認
git log --graph で、コミット間の関係をアスキーアートで表したログを表示できる
（やってみよう！）
47
Git の基本 ⑨： ブランチの削除
ブランチをマージしたとき、マージされたブランチは不要になる。
git branch -d コマンドにより、 test ブランチを削除せよ。
– ブランチを削除しても、コミットは消えない
48
0248e2a 2915339
master
test
f2324b0
＜イマココ！
2915339
$ git branch -d test
よりみち：マージされていないブランチの削除
マージする前に test ブランチを削除するとどうなるか？
ブランチ削除直後は コミット f2324b0 は残ったままだが、
Git リポジトリのガベージコレクション（ゴミ集め）の際に、削除されてしまう。
– ガベージコレクション は git gc コマンドで明示的に実行できる
– 暗黙のうちに行われることもある
49
0248e2a 2915339
master
test
f2324b0
＜イマココ！
$ git branch -D test
大文字の –D オプションで、未マージのブランチも強制的に削除できる。
← 残る（GCで消える）
関連する話題： GitHub
GitHub： インターネット上で Git リポジトリを提供するサイト。リポジトリだけでなく
– 課題管理（Issues）
– Wiki
– ユーザー間のプルリクエスト (Pull Request)
など、 オープンソース開発で必要な機能を多数揃えており、企業でも活発に使わ
れている。
近年の著名なオープンソースソフトウェア の多数は GitHub でホストされている
例：
– ビットコイン https://github.com/bitcoin/bitcoin
– TensorFlow (deep learning フレームワーク) https://github.com/tensorflow/tensorflow
– Linuxカーネル https://github.com/torvalds/linux
– Apache HTTP Server https://github.com/apache/httpd (ミラー)
– プログラミング言語 Kotlin https://github.com/JetBrains/kotlin ほか多くのプログラミング言語
50
Git応用 ①：分散機能を活用したリモート開発
https://github.com/keigoi/lecture-repo を開け。 (今井の講義用リポジトリ)
右のリンク Clone or download をクリックし、 https://github.com/ …..git
というリポジトリの URL をコピーせよ。
git clone コマンドにより、リポジトリをクローンせよ。
git clone は、リポジトリのすべてのコミットをリモートからダウンロードする。
(サイズが大きい・歴史あるプロジェクトだと、ダウンロードに時間がかかる)
52
$ cd ~ # ~ はチルダ。ホームディレクトリに移動する$ git clone (上で取得した URL)$ cd lecture-repo
0248e2a 29153390248e2a 2915339
http://github.com/... のサーバーローカルPC
クローン（＝コピー）
Git 応用②： git remote コマンド
git clone によって作ったリポジトリは、クローン元をリモートリポジトリとして参照し
ている。
git remote -v コマンドにより、リモートリポジトリを確認せよ。
– 上記は、 origin という名前でリモートリポジトリ https://.. を参照していることを示してい
る。
53
$ git remote -v
origin https://github.com/keigoi/lecture-repo.git (fetch)origin https://github.com/keigoi/lecture-repo.git (push)
origin/master
Git 応用③： リモートリポジトリからのフェッチ
講師（今井）が、 github 上の lecture-repo リポジトリの master ブランチに
コミットを加える。
git fetch コマンドにより、そのコミットをフェッチ（取得）せよ。
54
$ git fetch origin master
From https://github.com/keigoi/lecture-repo* branch master -> FETCH_HEAD
0248e2a 2915339
http://github.com/... のサーバーローカルPC
fetch 119ab340248e2a 2915339 119ab34
master master
＜イマココ！
Git応用④： リモートブランチ
リモートリポジトリからフェッチしたブランチを、リモートブランチと呼ぶ
– リモートブランチは "リモート名/ブランチ名" の形である。
git merge により、 master を origin/master に追随させよ：
（これを fast-forward (早送り) マージと呼ぶ ）
55
↓ リモートブランチ
origin/master
0248e2a 2915339
http://github.com/... のサーバーローカルPC
fetch 119ab340248e2a 2915339 119ab34
master master
origin/master
0248e2a 2915339 119ab34
master
＜イマココ！
＜イマココ！
$ git merge origin/master
Git応用⑤ Git のリモートの管理
git remote rm を使って、 GitHub リポジトリへの参照を削除せよ
https://github.com/gu-info にある、今日の最初に作った宿題のリポジト
リを開け
– https://github.com/gu-info/git-101-あなたのユーザーID という URL になっているは
ず
https … で始まるリポジトリ URL をコピーして、先ほどのリポジトリに
git remote add せよ
– ssh の URL は残念ながら PC 室からは使えません
56
$ git remote rm orgin$ git remote -v
$ git remote add orgin2 https://github.com/gu-info/git-101-あなたのユーザID.git
Git 応用⑥ リモートリポジトリへの プッシュ
やってみよう：
テキストファイルをコミットせよ。内容は何でも構わない。
git push コマンドを使って、そのブランチを origin2 にプッシュせよ。
注意：この宿題リポジトリは講義期間終了後、予告なく削除するかもしれません
57
$ git push origin2 master
参考資料
書籍 Pro Git の HTML版 https://git-scm.com/book/ja/v2
– 一番下の Appendix A3.2～A3.5 が、よいサマリーになっています。
Understanding Git Conceptually https://www.sbf5.com/~cduan/technical/git/
– Git の主要な概念を整理して解説しています。おすすめ
GitHub https://github.com/
BitBucket https://bitbucket.org/
GUI ツール
SourceTree (Atlassian社)
日本語の扱い・改行コードの扱いなどに注意
58
ソフトウェアテスト・ソフトウェア信頼性保証
59
再掲： ソフトウェア開発プロセス
60
要求分析
• 何をやりたいか・そのためにソフトウェアで何ができるかを分析する
• 要件を定義する
設計
• ソフトウェア全体の仕様を決める （外部設計）
• 各クラス（モジュール）の仕様を決める（内部設計・詳細設計）
• 要素技術（ライブラリやフレームワーク、アルゴリズム）を選定する
実装• 各クラス（モジュール）のプログラムを書く
単体テスト• 各クラスが仕様通り動作することを確かめる
システムテスト
• 全体として仕様通りに動作することを確認する
• 要件を満たしていることを確認する
リリース
• 受け入れテスト
• 本番環境にソフトウェアを配備（deploy：Webアプリケーションをサーバーにアップロードして動作状態にすること）
• マニュアルを作る、納品する
特に、この順序で実施するソフトウェア開発プロセスのことをウォーターフォールモデルと呼ぶ（リリースはプロジェクトの形態や契約（受託、自社開発）、ソフトウェアの稼働環境（Webサービス、モバイル、PC）等によって異なる）
ソフトウェアテスト
テスト：それまでの開発が仕様通りに正しく行われたことを確認する取り組み
– 人間は必ずミスをする → ミスを前提とした開発プロセスが必要 → テスト
– 品質保証： 欠陥を定量的に測定し、可能なものは修正する
– プロジェクトの状態は「健康」か？ 今、正しく物事が進んでいるか？
単体テスト・システムテスト
– 単体テスト（ユニットテスト）：モジュール単体について行うテスト
テストフレームワーク： JUnit などで記述する (Java)
– システムテスト： システム（ソフトウェア）全体のテスト
受け入れテスト
– 顧客側で行うテスト（開発者と顧客が異なる場合）
– 「これは仕様通りか？」と、この段階で「蒸し返される」こともある
– 互いに合意した品質を達成するまで改修とテストを繰り返すことも多い
– 受け入れテストが完了しないと納品が完了しない → 納期の遅れ、コスト（人件費等）の上昇
61
ユーザーインタフェースの自動テスト (Android Studio で利用可能なもの)
Espresso
– アプリの内部構造にアクセスできる
– 一般にアプリのソースコードが必要
– 比較的に安定
UI Automator
– アプリに依存しない、ユーザーインタフェース操作を記述可能
– タイミングに依存する（特に非同期的な）操作について注意が必要
参考：https://developer.android.com/topic/libraries/testing-support-library/index.html
62
課題の前に：ドキュメントの調べ方、サンプルコードの使い方
63
ライブラリの導入
Android の既存機能では不足する場合には外部ライブラリを導入する
ライブラリの導入方法： app/libs/ 以下に jar をコピーし
右クリック ⇒ Add as library
Mavenリポジトリに登録されているライブラリの場合：
– app/build.gradle の dependencies{...} に書く
– ライブラリの識別子やバージョンは http://mvnrepository.com/ で調べられる
64
ライブラリ・フレームワークに慣れるには
Android に限らず、現代的なソフトウェアは外部ライブラリやフレームワーク
の利用がほとんど
ドキュメントの引き方、 Web検索で必要な情報を収集する方法を知っておこう
基本：
– 開発元の情報のみが正式かつ信頼できる情報源 (Android であれば Google)
– ブログは信頼できない。 まずはサイト内検索で開発元を探す
– 長い文章を素早く読む、英語に慣れる、ソースコードを読む
Android プログラミングの細かい方法については教えません
– Android開発を習得するための講義ではなく、、、
「自主課題製作を通じて、プログラミングの知識や技術を確実なものにする。あわ
せて、研究開発など実践的能力を養う。」
– ドキュメントの「読み方」を身に着けて、後は自分で覚えてください
65
例： ConstraintLayout の使い方を調べる
Google で ConstraintLayout 使い方 と検索すると…
66
日本語のブログばかりヒットする⇒記事の品質を判断できますか？
Google によるサイト内検索
Google 検索で、 site:URLの一部 と検索すれば、そのURL以下のみ検索
例：ConstraintLayout site:android.com で検索
67
Google によるサイト内検索
Google 検索で、 site:URLの一部 と検索すれば、そのURL以下のみ検索
例：ConstraintLayout site:android.com で検索
68
Google によるサイト内検索
Google 検索で、 site:URLの一部 と検索すれば、そのURL以下のみ検索
例：ConstraintLayout site:android.com で検索
69
Google によるサイト内検索
Google 検索で、 site:URLの一部 と検索すれば、そのURL以下のみ検索
例：ConstraintLayout site:android.com で検索
70
それでも日本語が読みたい時は
Android関係書籍の著者の記事は信頼できそう
– 著者の例： http://techbooster.org/
Qiita, はてなブログ等、技術情報が集積しやすい技術ブログサイトを優先
すると良いかもしれません
71
英語に慣れよう
使っている端末の言語設定を英語 (en_US) に設定しよう
(Windows 以外)
– Android、iPhone、macOS、Linux
72
Android 開発で読んでおくべきドキュメント
Android Studio の概要 (日本語) 必読
https://developer.android.com/studio/intro/index.html
Android入門 （日本語）
https://developer.android.com/guide/index.html
– 左のメニューバーでなるべく多くのドキュメントに目を通しておこう
– 何かあれば、このページから必要な基礎知識を必要に応じて得ていきましょう
今いくつか読んでみましょう
73
Android サンプルコードの利用
ライブラリの使い方がわからない時は、やみくもにググるのではなく、
Android 公式のサンプルコードを調べてみよう
File -> New -> Import Sample (上から6つ目)
– サンプルをインポートすればすぐに動作確認できる
74
ソフトウェアテスト：続き
75
既存OSSプロジェクトのテストの例
単体テストを見てみましょう
Commons-IO
– Javaの入出力関連の便利ライブラリ
1. デスクトップの 「Androidプロジェクト作成準備」 で commons-io と入力、エンター
2. メニュー VCS → Checkout From Version Control → Git
3. Git Repository URL: https://github.com/keigoi/commons-io.git
4. Parent Directory: Z:¥AndroidStudioProjects
Directory Name: commons-io
76
https://github.com/keigoi/commons-io.g
Z:¥AndroidStudioProjects
commons-io
Commons-IO の単体テストの実行
ビルドが終わったら test/java を右クリック、Run 'All Tests'
77
既存OSSプロジェクトのテストの例②
Twitter4j
– Java用の Twitter ライブラリ
1. デスクトップの 「Androidプロジェクト作成準備」 で twitter4j と入力、エンター
2. メニュー VCS → Checkout From Version Control → Git
3. Git Repository URL: https://github.com/keigoi/twitter4j.git
4. Parent Directory: Z:¥AndroidStudioProjects
Directory Name: twitter4j
78
https://github.com/keigoi/commons-io.g
Z:¥AndroidStudioProjects
commons-io
前提条件をもつテスト、ネットワーク接続を用いるテスト
多くのメソッドが例外で落ちる： Twitter の認証情報が必要なテスト：
– テストの実行に必要な test.properties が無いため
– test.properties-template をコピーして、自分の Twitter の認証情報を入れれば
動作すると思われる
79
UIテストの例
UI Automator によるテスト
ui/uiautomator/BasicSample を Android Studio で開く
app/java/ChangeTextBebavior を実行
– ホームボタンを押し、アプリを起動し、テキストに入力するという一連の動作が
自動化されている
– スマホゲームの稼ぎ行為にも使えるかもしれない
（やらないのでわかりません；BANされても責任はもちません）
80
cd /z/AndroidStudioProjectsgit clone https://github.com/googlesamples/android-testing.git
Git Bash で：
課題②の準備：課題リポジトリの Clone
課題その2 を 以下の URL で accept してください
https://classroom.github.com/a/jjH4AX3U
https://github.com/gu-info/androidtest-あなたのID
に、課題リポジトリができたことを確認してください
課題リポジトリを Android Studio にインポート (Clone) してください
1. デスクトップの 「Androidプロジェクト作成準備」 で WebSurfer プロジェクトを準備
2. メニュー VCS → Checkout From Version Control → Git
3. Git Repository URL: https://github.com/gu-info/androidtest-あなたのID
Parent Directory: ワークスペースの 相対パス (Z:¥AndroidStudioProjects)
Directory Name: WebSurfer
81
https://github.com/keigoi/progjissen2-...
Z:¥AndroidStudioProjects
課題② ： JUnit によるユニットテストとUIテスト：概要
課題リポジトリには、クラス Downloader と、そのユニットテスト DownloaderTest
（テストケースと呼びます）が含まれています
– Downloader は URL からデータをダウンロードするクラスです
– 「指定したドメインからのダウンロードを禁止する」という機能拡張をしてください
Downloader は未完成の状態であり、このままではユニットテストが失敗します
課題
1. 今あるテストケースがすべて pass するように、 Downloader の実装を修正してくださ
い（ヒント：次頁以降）
– このように、先にテストを書いてから実装に進む方法をテストファーストと呼びます
– テストコードはこれから書くコードの仕様を表現しています
2. 更に、テストケースに一つテストを追加してください (DownloaderTest で
removeBannedDomain メソッドについてテストを追加)
82
課題② ユニットテストの実行
app > app > src > test/java > jp/ac/gifu_u/info/lec/prog2/websurfer >
DownloaderTest を右クリックし、 Run 'DownloaderTest' をクリックしてください
83
成功したメソッド：緑色のアイコン失敗したメソッド：オレンジor赤色のアイコン
課題② テストファースト
1. Downloader クラスを開き、 addBanned, removeBanned メソッドの中身を実装
してください
– TODOのコメントは削除してください
– ヒント： フィールド bannedDomains は ArrayList クラスのオブジェクトで、ここに禁止ド
メインのリストを追加します
– ArrayList の add, remove メソッドを使います
– 参考： http://docs.oracle.com/javase/jp/7/api/java/util/ArrayList.html
2. download メソッドを、禁止ドメインが渡された場合に false を返すように修正して
ください
– ヒント： bannedDomains を for文で回します。 以下のどちらか
テストがすべて成功することを確認してください
84
for(String domain : bannedDomains) {if(url.getHost().endsWith(domain)) {…}
}
for(int i=0; i<bannedDomains.size(); i++) {String domain = bannedDomains.get(i);if(url.getHost().endsWith(domain)) {…}
}
課題② ユニットテストの実行(3) テストの追加
removeBanned_download_success メソッドの中に、
Downloader#removeBanned メソッドが正しく動作することを確認するテストを追
加してください
– ノーヒント
85
課題 提出準備：ローカルリポジトリへのコミット
ウィンドウ下の Version Control をクリック
Local Changes に、変更したファイルの一覧が出る
コミット対象のファイルを選択して Commit
(コミット時のレビュー警告等は今回は無視する）
86
コミット
コミットメッセージを入れる（「課題提出」「Downloader の ドメインban機能の追加」など）
課題 提出準備：ローカルコミットの確認
ログを表示し、先ほどのコミットが成功していることを確認する
87
課題提出： git push
メニュー→ VCS → Git → Push
– GitHub のページで正しくプッシュされることを確認する
– 不安な人は今井まで聞きにきてください
88
補遺： 既存の Android Studio プロジェクトの Git 化
VCS → Enable Version Control Integration
前回のプロジェクトも Git 化 してみましょう
89
