はじめまして。
bewise.jpやまうちと申します。
ソフトウエア関連の仕事をしていた機械メーカーを退職し、現在はIT研修のアシスタント講師などをさせていただいています。
今回、仕事の幅を少しでも広げるべく、そしてソフトウエア開発に関連する知識を再確認するということも目的として、プログラムを作りながら学んだこと、考えたことなどを書いていきたいと思います。
はじめに
今回の企画は、先に書いたようにプログラムを書くことを通してプログラミングをしていくうえで学んだこと、考えたことを書いていくことで自分の中でプログラミングに関する知識を整理することを目的としています。
そのため、ある程度の規模のプログラムを作成することを目標にプログラムを少し書いてはそれに関連する項目を書いていくといった形式で進めていこうと考えています。
ということで、何を作ろうかという検討です。
まず、ゲームはやりません。プログラマーの仕事としてゲームは魅力的ですが、ゲームの本質はプログラム自体ではなくルールなどのゲームシステムにあり、ゲームの魅力はキャラクターグラフィクスなどの要素に深く依存していることを考えるとプログラミングだけでゲームを作っていくのは面白くなさそうというのがその理由です。
そしてAIも (たぶん) 扱いません。ニューラルネットワークを作ったところで学習や訓練を行わないとAIとしては機能しませんし、学習済みのニューラルネットワークを使うだけならプログラミングとしてそれほど面白いところもなさそうというのがその理由となります。ただ、なにか面白そうな話題があれば手を出すかもしれません。
もう一つ大事なことは自分が使おうと思うようなプログラムにしたいということです。
このプログラムができればこんないいことがあるぞといった要素があれば、実現する目標に向かってやる気も出るだろうというのがその理由です。
ということで、今回はありきたりですが小遣い帳を作ってみようかと思います。
なにを作るか
ということで何を作るか具体的に考えていきます。
まず、最初に小遣い帳でやりたいことをはっきりさせなくてはならないので、やりたいことを書き出していきます。
収入、支出、振替が記録できること。収入、支出を記録することはもちろんですが、キャッシュレスが多くなってきたのでクレジットカードの利用代金支払いや何とかペイへのチャージなど複数の財布を持って、財布の間で資金を移動する必要が増えてきたので、振替も記録する必要があると考えました。
様々な種類の財布の残高を確認できること。複数の財布があると全体として残高がいくらあるのかが分からなくなってしまいます。このため、財布それぞれの残高を管理できるようにするとともに、全体でどれだけのお金があるかと借入金、クレジットカードの利用残高、がどれだけあるかを把握できる必要があると考えます。
クレジットカードの利用確認ができること。クレジットカードの利用代金請求時に該当する取引の一覧と消込を行えるようにして、不正請求などが発生していないことを確認できるようにしたいと思います。
繰り返しの入金、支払いを簡単に入力できること。公共料金のように金額が変動する定期的な支払い、主食費などのように不定期だけれどもそれなりの頻度で発生する支払いなどを簡単に入力できる仕組みがあるとうれしい思っています。
費目ごとの金額を管理できること。費目ごとにどれだけの支払いを行っているかを把握して、家計の見直しにつなげていければいいのではないかと考えています。
予算管理ができること。将来的には費目ごとの予算を設定して費消状況を確認することにより家計の健全化につなげられればと思います。
貯蓄・投資を管理できること。貯蓄に関してはあまり難しいことはありませんが、株式や債券、投資信託などは価格変動があるため、どれだけの資金を投入して、どれだけ利益が得られたかが管理できればいいのではと思っています。
上に書いたような要求事項とは別にプログラムとしてできればいいことも書いておきましょう。
アプリケーションの形態。スタンドアロンアプリケーションにするか、Webアプリケーションにするかは難しいところです。とりあえず簡単に作れるのはWebアプリケーションなのでWebアプリケーションとして作成し、スタンドアロンアプリケーションにも将来的には対応できるように考えたいと思います。
セキュリティ。インターネット上で利用できる携帯にする場合はセキュリティ対策が重要になってきます。今回は自分だけで使うことを前提にインターネット上には見せない形とすることでセキュリティ関連は最小限としたいと思います。そしてもちろんユーザ登録やログインなどの仕組みも当面は入れないことにします。
性能。個人的に使用することを前提に性能目標値は決めないことにして、使ってみて気になるところがあれば改善するというアプローチにしたいと思います。
本式のソフトウエア開発ではこれらの要求事項を精査して、それぞれの要求事項に対する具体的な目標値を設定する要件定義を行うわけですが、要件定義をグダグダやっていても面白くないので、とりあえずはこのレベルで先に進めようと思います。
どう作るか
次はどう作るかという話になります。
本式のソフトウエア開発では要件定義の結果からシステム規模を推測し、自分たちの保有技術の中から最適なものを組み合わせていくわけですが、今回は学習が前提ですので決め打ちで進めていきます。
ということで初期開発はJavaとServlet、JSPで進めていこうと思います。
最近は様々なプログラミング言語が実用レベルで利用されるようになっており、Javaはすでに古典の域に達していると思います。
なので、新しいプログラミング言語に挑戦する必要も感じているのですが、環境や事例などが豊富でアクセスしやすいという点からJavaが学習としては取り組みやすいだろうということと、様々なプログラミング言語が利用されるようになってはきていますが、現時点でもJavaは広く利用されているのでJavaを学ぶ必要がなくなったわけではないというところからJavaを選択しています。
また、Webアプリケーションのプラットフォームとして、Springなどがひろく普及していますが、学習という観点ではプラットフォームの持つ魔法がどのように動いているかを想像できるようになる、基本的な技術的理解が必要ではないかということでWebアプリケーション構築環境としてはプリミティブに近いServletとJSPを使用することとしました。
もちろん、新しい技術への対応も必要ですので、様々な技術も将来的には取り組んでいきたいと思います。
とりあえず手を付けてみる
ということで早速作ってみることにします。
といっても、まだほとんど何も決めていない、建築で言えば4LDKの家を木造で建てるよと決めたくらいで、間取りをどうするか、平屋にするか二階建てかといったことさえ決まっていない段階です。
なので、大規模なソフトウエアであれば基本設計とか概要設計とか外部設計とかいうものを行ってそれぞれの機能の概略を決めるとともに機能間のつながりなども決めていくのですが、今回はとりあえず適当に進めていこうということで、そういったこと抜きにガシガシ進めていこうと思います。
まず、要求事項から機能を並べていきます。
収入、支出、振替の記録
財布ごとの入金・支出・残高の管理
クレジットカードの利用確認
繰り返しの入金、支払いの入力
費目ごとの金額管理
予算管理
貯蓄・投資の管理
これらの機能の中で手の付けやすいところ、あるいは最初にないと困りそうなところから手を付けていこうと思います。
最初は一番の大枠になる取引 (収入、支出、振替) の記録のところから始めることにします。
Webアプリケーションのいいところは、とりあえずHTMLでユーザインタフェースの出来上がりイメージを作ってみることできるので、とっつきやすいところだと思います。
ということで取引の表示画面と入力画面を作ってみます。
今回プログラミングで使う道具はPleiades All in Oneという日本語化対応を行った統合開発環境EclipseにJava開発に必要なツール類を同梱したものを使用します。
Eclipseのインストールと操作の詳細は省略して、とりあえず新規動的Webプロジェクトとしてcashbookプロジェクトを作成しました。あまりがんばる必要はないのですが、サーバーランタイムはPleiadesに添付されている最新のTomcat10、Javaバージョンは21にして、動的Webモジュールのバージョンは6.0を選んでみました。
動的Webモジュールバージョン6.0はパッケージ名が変更になっているところから従来のバージョンと異なっているので、既存のライブラリなどと組み合わせる場合には注意が必要ですが今回はWebテンプレートなどを使用しない方向ですので、Pleiades同梱の最新バージョンとしてみました。
できあがりイメージを作ってみる
まず最初に、取引の表示画面と入力画面のできあがりイメージを固定のHTMLファイルとして作ってみます。
画面イメージを作ってみることで表示や入力に必要な項目の洗い出しができますし、作ったHTMLファイルはJSPファイルの骨格として利用できるからです。
外部設計を行う際に画面仕様書を作成することになると思いますが、こういった場合にもHTMLファイルで画面例を作成する方が手書きで絵を描くよりも効率的ではないかと感じています。
まず、取引表示画面です。
ただ表示するだけのHTMLは動的Webプロジェクトの "src/main/webapp" フォルダに作成します。EclipseはTomcatなどのサーブレットコンテナに "main" フォルダ以下を展開し、サーブレットコンテナはwebapp以下にあるファイル、フォルダ (META-INFとWEB-INFを除く) をWebクライアントから参照できるようにしますので、webappフォルダにHTMLファイルを置くだけでブラウザから確認できるようになります。
とりあえず必要そうな項目として「取引日」、「種別」、「項目」、「取引先」、「金額」の5項目を挙げて並べてみました。
対応する入力画面はこんな感じになります。
これだけを作っただけでもいろいろと考えるところが出てきます。
最初の問題として、取引の入力だけでなく修正や削除もできないといけません。そうすると取引表示画面は単に取引を一覧表示するだけでなく、編集や削除の機能を持ったものになり、取引入力と一体で運用されるべき画面になります。
そんな考察を反映して、以下のような画面を作ってみました。
各行ごとに「修正」「削除」のボタンを用意して、それぞれの行の内容を修正、削除できるようにします。また、取引入力用画面を統合して、同じ画面から新規入力できるようにしました。
この画面での操作と動作も決めておきます。
新規入力の場合、下段に入力を行って「登録」ボタンをクリックすることで新規取引が記録されます。
「修正」ボタンがクリックされると下の入力エリアに内容がコピーされるので編集して「登録」ボタンをクリックすることで取引の修正ができます。ただ、新規入力なのか修正なのかが画面上で判断できるようにしておいた方がよさそうな気がします。
「削除」ボタンに関しては一度確認操作を入れる必要がありそうです。
ということで少し手直しをしてみました。
画面上は「操作内容表示」となっていますが、この画面が表示された最初の状態では「操作内容表示」のところに「新規取引入力」と表示がされます。
取引一覧で「修正」ボタンがクリックされると「操作内容表示」の部分に「取引修正」と表示され、各項目に既設定内容が表示されます。設定内容編集後に「登録」ボタンがクリックされると「操作内容表示」は「新規取引入力」に戻ります。
取引一覧で「削除」が選択されると「操作内容表示」の部分に「以下の取引を削除します」と表示され、各項目に設定内容が表示されます。併せて「登録」ボタンが「削除」ボタンになりこれをクリックすると項目が削除されて「操作内容表示」は「新規取引入力」に戻ります。
「修正」や「削除」はやめたい場合、例えば違う行をクリックしてしまった場合などがあります。別の行をクリックすれば修正・変更の対象行が変わるのですが、新規入力に簡単に戻ることはできません。このため、「修正」「削除」が押された際の画面には「登録」ボタンの横に「キャンセル」ボタンを表示して「新規取引入力」に戻れるようにした方がいいかもしれません。
ここまでで概略の動作は決めることができましたが、まだいくつか検討すべき事項が残っています。
まず、表示の順序をどうするか、日付順に並べるのはいいとして、同じ日付で複数の項目がある場合はどういう順序で並べるかを決めなければいけません。
ほかにも入力項目が不適切な場合、例えば取引日が未入力の場合にはどうするかといったことも考えなければなりません。
こういったことを決めてから次の工程、一般的には詳細設計ですが、今回はそこを端折ってコーディングとテストに行こうと思います。
ということで次回はコーディングに入っていきたいと思います。
この記事が気に入ったらサポートをしてみませんか？