JPG画像の解像度(DPI)変更アプリの開発（２）ー設計
本記事ではDPI Changerの設計について解説します。
アプリ開発の流れは大体下記のようになります。
・概要設計
・詳細設計
・プログラム設計
・製造
・単体テスト
・結合テスト（他機能との連携等の観点）
・総合テスト（中・大規模システムの場合、他サブシステムとの連携等の観点）
・お客さん受け入れテスト（会社によって、ユーザテストとかシステムテストとか呼び方が違います）
・リリース
・運用サポート
DPI Changerは機能がシンプルなアプリなので、結合テスト、総合テストまではやりようがないですが、このシリーズをきっかけに開発の全体イメージがすこしでもできれば嬉しいです。
１．概要設計
概要設計では何をするか(What to do)」に注目して書いたほうがいいでしょう。
筆者の頭の中でのイメージでは、概要設計者は「（間違った方向に偏らないように）道を指す」人であって、詳細設計者は「どうやって歩けばいいか詳しく考える」人です。
①画面・画面遷移
DPI Changerは画面が１つしかないのでシンプルですが、画面が複数ある場合はこの段階で画面遷移図（どのボタン押せばどの画面出す、を矢印で繋いだもの）も必要になったりします。
②処理
１．「DPI値」
・変更したい値を数値で入力する。
２．「画像フォルダ」
・変更したい画像のフォルダを入力する。
・ドラック＆ドロップ操作もサポートする。
３．「参照」ボタン
・ディレクトリ選択ダイヤログを表示し、選択されたフォルダを「画像フォルダ」に表示する。
４．「実行」ボタン
・「画像フォルダ」配下のすべてのJPGフォーマットの画像のDPI値を「DPI値」に入力した値で書き換える。
５．「メッセージ表示欄」
・変更した画像のファイル名、処理結果（OK/NG)を表示する。
・最後の行に画像の数、正常終了数、異常終了数を表示する。
③その他
・開発言語は C#
・.Net Framework 4.0のwindows form方式
上記のような概要設計で、画面のイメージと処理内容が大体分かってくるはずです。概要設計書は次の「詳細設計」のinput資料になるので、「画面はどんな感じで、どのような処理がほしいか」のような要求を簡潔且つ明確に記述するのがポイントになります。
ほかのシステムとの連携処理が必要な場合は、連携方式なども概要設計段階で決めておく必要があります。例えば、「連携処理はファイルベースで行うかそれともDB経由でおこなうか」、「ファイルベースの場合はCSVフィルなのか、xmlファイルなのか、固定長テキストファイルなのか、等など。
さらにDBを使う場合は、oracleか、MS SQL Serverなのかそれとも無料のMySQLか、PostgresSQLなのか等もすべて決めておく必要があります。
２．詳細設計
概要設計書の画面設計を引き継いで、画面上の各部品を詳しく定義し、必要な各イベント処理についても詳しく記述します。
①画面設計
□DPI Changerの画面設計
画面の各部品と、処理の詳細設計は下記の感じになります。
画面上の各部品をどのコントロール(C# winform方式の画面要素）で作成し、初期値はどうするか、など詳しく定義しています。
イベントの処理内容にも、実現したい動きを詳しく漏れなく記述するのが望ましいです。
上記のような詳細設計書を作成する人をシステムエンジニア（略称：SE）を呼びます。
実はシステムエンジニアは必ずプログラミングができるとは限りません。SEってあくまでも設計者です、実際にプログラミングを行う役割ではありません。（プログラミングする人をプログラマーと呼びます。製造（実装）段階を「コーディング」と呼ぶ会社もあるので、その場合はプログラマーのことを「コーダー」と呼ぶこともありますね。）
システムエンジニアの役割は、お客さんの要望と概要設計書を十分に理解し、実現すべき処理内容を詳しく詳細設計書に記述し、プログラマーに渡すことです。そして、SEは概要設計から必要なすべての処理を詳しく考える必要があります。他システムとの連携などの処理がある場合は、その連携方式についても詳しく仕様を決める役割です（例えばCSVファイルで情報連携するとした場合、CSVファイルのレイアウトとか仕様を定義することもすべてSEの仕事になります）。
これらの仕事は、プログラムの仕様書作成に慣れれば、そしてプロジェクトの要望をよく理解したら、（プログラミングができない人でも）十分に書けるものです。
筆者は実際にIT現場でjavaがぜんぜん分からないwebアプリ設計者に会ったことも何回かあります。画面設計、処理内容の記述とかはあくまでも「何を作ってほしいか」であって、「どうやってプログラミングするか」ではありません。（実は文科系の人がIT企業に就職することもたくさんいます）
上記の「実行ボタン押下」の処理内容も、「なにをしてほしいか」の記述であって、「どうやってプログラムを書くか」ではありませんね。とりあえずこのような処理を実現できればいいので、「具体的にC#でどうプログラミングすればこのような内容を実現できるか」を考えるのはプログラマーの仕事ですね。
十人十色で、実際にIT会社も設計段階での基準は色々です。この会社で詳細設計はこんな感じで書いたのに、ほかの会社に行ったら詳細設計書は又別の感じになることはたくさんあります。
フォーマットから全く変わった感じになることもたくさんあります。例えばA社ではExcelで詳細設計書いたが、B社にいったらWordで詳細設計書書くとか。
又、A社では詳細設計といっても、B社ではさらに細分化されて「外部設計」、「内部設計」だったりとか。
筆者は東京でいろんな会社（EC関連の最大手やwebサービス開発関連や通信関連の大手等）に常駐した経歴がありますが、概要設計とか詳細設計のやり方はすべて違いましたね。
なので、IT会社に就職すれば最初はその会社の設計書の書き方になれる必要があります。
上記の「実行ボタン押下」の処理の記述方法についても、会社によっては下記のような詳細設計書になることもたくさんあります（上の詳細設計とやることは全く同じですが、書き方が全然違います）。
これはC＃言語でコードを書いてなかっただけで、完全にプログラムになってますね。製造者がC#言語でプログラミングするときも、このようなコードを書くことになります。
多くのシステムエンジニア（SE）は、プログラマー時代を通って経験など積み重ねてSEになってるので、SEになってからも詳細設計書を作成するときはまだ「頭の中ではずっとプログラミングをしている」訳です。なので書いた詳細設計書も、「文字で書いたプログラム」にならざるをえません。
DPI Changerの開発とは関係ない余計は話になりますが、アプリ製品の開発にはいろんな理論知識があって、また開発工程は要件定義、概要設計、詳細設計、プログラミング設計、製造、単体テスト、結合テスト、総合テストなどに分かれます。。。とかあるけど、実際多くの会社ではコストを一番重要視しがちです（お金の話なのでもちろんでしょうけど）。
コスト優先なので、実際には概要設計、詳細設計が全部できる技術者を求めたり、プログラミング設計、製造、単体テスト、結合テストをすべて同じ技術者に任せる、といったケースがよくあります。
その場合、概要設計・詳細設計と分けなくて一気に詳細設計書だけ作成したり、プログラミング設計書は省略されたりすることが多いです。
このようなことも、実際に自分が就職した会社のやり方に従うべきでしょう。
②その他
DPI Changerはシンプルで画面１つで終わるのですが、一般的のアプリは外部連携処理とかバッチ処理とかDBアクセス処理とか沢山あります。
その場合、詳細設計段階では
・外部連携処理設計（方式、連携ファイルレイアウト、処理内容等）
・バッチ処理設計
・（バッチを何時起動するか等が書いてる）バッチ運用設計（ジョブネット図と呼ぶことも有）
・DB設計（テーブル定義書、ER図等）
・マスタデータ設計（マスタテーブルの初期データ）
のようなたくさんの設計書を作成する必要があります。
（アプリ開発ってまじ面倒くさいっすね）
３．プログラム設計
ここから初めてプログラミング言語と関係される設計書になります。
「開発に選ばれたプログラミング言語で上記詳細設計の内容をどうやって実現すればいいのか」、の内容を記述するのがプログラム設計になります。
ここからはプログラミングができないと（C＃分からん！の方は）作れないはずですね。
C#で開発する場合、クラス図、シーケンス図は下記のようになります。
①クラス図
上記がDPI ChangerをC#で開発する場合の、クラス図になります。上記の図をUMLと呼びます。プログラマーだったら、最低限UMLは把握してほしいものです（よく使うのはユースケース図、アクティビティ図、状態遷移図、クラス図、シーケンス図、コンポーネント図等）。
実際の現場では、上記のようなクラス図を作成したらみんな見て分かる前提になります。
今回はnote文章なので、下記にクラス図の説明文を書いておきます。
□クラス「Program」
これはC#でwindows form方式アプリを開発する場合の定番のクラスです。
自動作成され、メイン画面の呼び出し（実行）処理も既に自動作成されています。特殊な処理を行わないかぎり弄る必要はありません。
□クラス「FrmMain」
メイン画面のwindows form型クラスになります。
DPI Changerが実行されると、該当クラスが実行され（メイン画面が表示される）、押された各ボタンのイベント処理を行います。
□クラス「JpegFormat」
JPG(JPEG)画像ファイルがJFIF形式なのかEXIF形式なのかを記録するクラスになります。
□クラス「ResolutionInfo」
解析した解像度情報(X方向、Y方向の2つの値がある）と、画像ファイル内での格納場所（オフセット）を保持するクラスになります。
DPI Changerはシンプルなアプリなので、構造も簡単で、上記のように大まかに３つのクラスで作成されています。
②シーケンス図
シーケンス図では、アプリが起動されると「どのタイミングでどのクラスのどのメソッドを呼び出すか」、「どのような引数を渡すか、何が返されるのか」、「どこで繰り返すのか、どこで例外キャッチするのか」等などを明記できますので、完全にプログラムの世界になります。
「プログラムのすべての処理を図で表現した」のがシーケンス図になります。
※案外の話
「概要設計」、「詳細設計」は実際にプログラミングができない人でも作成できる設計書になります。
逆に「プログラム設計」と次回解説する「製造」はもちろんプログラミングができないと絶対ダメですね。
ここで一番ややこしいのが「プログラム設計」です。多くのIT会社ではこの「プログラム設計」という段階がありません（開発コストの問題でしょう）。なので「プログラム設計って聞いたこともねぇよ」って方も多いでしょう。
さらに、「UML？聞いたことねぇ～よ」って方は、レベルの問題になります。UMLは必ず勉強したほうがよいでしょう。
「プログラム設計」がないといった場合、どうでしょう。実はプログラマーが頭の中で考えて、そのままプログラムを書いたことになります。（プログラム設計書を作成しなかっただけで、実はプログラマーが頭の中でプログラム設計を行っています）
この場合、（プログラムの設計を頭の中で行いながら製造することになるので）プログラマーのレベルが問われることになりますね。
多くの場合は、SEのほとんどはプログラマー時代を通って詳細設計者になったはずなので、詳細設計をするとき、すでに頭のなかにはプログラムができています。なので、実際にプログラマーが迷ったりする場合はアドバイスもできるし、シーケンス図などを詳細設計段階で作成することもあります。
この場合はプログラマーのレベルがあんまり高くなくてもついていける感じになります。
ちなみに筆者が愛用するUML作成ツールはastahというソフトです。昔は完全無料でJudoという名前だったんですが、そのあとastahと名前が変更され、しかも現在は有料版になってしまいました。んんん。。。
下記はastahで上記のクラス図を作成した場合の画面になります。
筆者は色で既存のクラスと自動作成されるクラスや新規作成すべきクラスなどを表現しています。
そして、既存のクラスならどの名前空間にあるのか等も赤枠のように表現しています(astahはUMLの王者だと思いますが、有料になったので、個人でUML作成する場合は他のソフトにチェンジします）。
まとめ
本記事ではDPI Changerの設計方法について解説しました。
DPI Changerアプリの開発に関する全般的な流れについて解説する記事ですが、これだけではなく、一般的にIT会社内でアプリ開発する場合の流れについても触れているので、アプリ開発の全体的流れがイメージできたら幸いです。
次回はDPI Changerの製造について解説します。
DPI Changerだけではなく、アプリ開発の全般に於いて上記のような設計段階を必ず通すことになります。
では、
バイバイ！ Have a nice day!
この記事が気に入ったらサポートをしてみませんか？