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

こんにちは。

今日は、システムの開発手法の一つであるウォーターフォールモデルについて書いてみます。

最近では、アジャイル開発の方が効率的と言われていますが、
大手のシステム企業では、ウォーターフォールモデルを使っています。

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

先ほども書きましたが、ウォーターフォールモデルとはシステム開発手法の一つです。

以下のように工程を分けてシステム開発を進めていきます。

• 仕様書作成
• 基本設計
• 詳細設計
• 製造（コーディング）
• 単体試験
• 結合試験
• 運用試験
• 納品

各工程で納品物が決まっており、納品物のレビューしたのち、作成者、作成企業、発注企業で押印し納品されます。

そもそもウォータフォールとは滝の意味で、水が上から下へ流れ落ちるように開発する手法です。

工程も、上流工程と下流工程とに分けられ、上流工程は、仕様書作成、基本設計が含まれ、下流工程には、詳細設計、製造、単体試験、結合試験、運用試験が含まれます。

メリット

各工程において、全員が納得した納品物を作成するため、明文化された書類、設計書があり次の工程へすぐに入ることが可能です。

また、後戻り作業が発生しないというのもウォーターフォールモデルの特徴です。

技術者は前工程で納品されたものに集中し作業することができ、スケジュールの遅れも少ないとされています。（実際には、技術者の経験等によりスケジュールが遅れることがよくあります。）

見積りも工程ごとに行うことが可能で、上流工程（仕様書作成、基本設計）と下流工程（製造、単体試験、結合試験、運用試験）で金額が変わることがよくあります。

そのため、上流工程をベテラン技術者が行い、下流工程を若手が行うことで、若手の育成を行うことも可能です。

デメリット

デメリットとしてまず上げられるのは、仕様書作成から納品までが長いということです。

時には数年を費やすこともあります。

そのため、納品され実働に投入される頃には、開発言語が古くなっていたり、時にはセキュリティ上の不具合が含まれることもあります。

また、納品までに時間がかかるため、金額も高くなります。

そして、1番のデメリットは、機能の追加・修正ができないということです。

実際には、機能の追加も同時に行うのですが、前工程の納品物から作り直しになり、再度、レビューや押印が必要となるので、さらに時間がかかります。

まとめ

ウォーターフォールモデルでは、若手の育成ができる良い面もありますが、システム開発の期間が長く、金額も高くなるなります。

しかし、工程ごとにきちんとした物が出来上がるため、大手システム企業では今だに使用されている手法でもあります。

そのため、これからプログラマーを目指す方は、ウォーターフォールモデルでの開発を調べておくと、実戦で役に立つかもしれません。

では、今日はこの辺で。

クラス設計とは

こんにちは。

今日は、クラス設計について書いてみようと思います。

クラス設計で大切なのは以下の３点です。

• 基底クラスを作る
• 継承を使う
• リファクタリングを行う

最近は、フレームワークを使うため、いちからクラス設計することはありませんが、クラス設計は、知っていると結構役に立ちます。

クラス設計とは

クラス設計とは、システム開発の詳細設計の工程で作成する設計書の１つです。

クラス図とも呼ばれ、クラスの関連性を図示したものです。

クラス設計がなぜ大切かと言うと、同じ処理を何度も書かないためです。

同じ処理を異なるクラスで書くと、修正する際に大変になりますし、不具合の原因となります。

どのクラスで、どの処理を行うかで、ソースコードが綺麗な読みやすいものになるかを左右します。

綺麗なソースコードは、不具合が少なくなります。

では、以降でクラス設計で大切なことを説明していきます。

基底クラスを作る

基底クラスとは、継承元となるクラスです。

スーパークラスとも呼ばれ、全てのクラスで使用できる変数や関数をコーディングします。

フレームワークを使用していると、基底クラスを作らず、フレームワークのクラスを直接継承し作成することもあるのですが、なるべくフレームワークのクラスを継承する基底クラスを作ることをお勧めします。

経験上、設計・コーディング・リファクタリングしていくと、同じ値を保持することがよくあります。

例えば、状態を保持する変数は、基底クラスで設定し、状態繊維の処理も基底クラスにコーディングすることで、状態の不一致で不具合となることが減ります。

また、例外処理を基底クラスでコーディングするとで、継承先のクラスでは処理に専念することができます。

継承を使う

新しいクラスを作る時は、継承して作成しましょう。

単体のクラスをすぐに作るプログラマーも多いのですが、フレームワークを使用すると、ある程度の必要な処理はフレームワークに含まれています。

せっかく信用あるフレームワークを使用するのですから、フレームワークで用意されている処理は使うようにしましょう。

無理に独自処理を組み込むことは、セキュリティ上の脆弱性を組み込んでしまう可能性もあります。

昔々は、ステップ数が多い方がいいという時代もありましたが、現在は、安全性が重視されます。

リファクタリングを行う

ソースコードは、リファクタリングしましょう。

動くソースコードが出来上がったら、試験の工程へ移行しますが、ソースコードは、何度もリファクタリングを行うことで、より綺麗なソースコードとなります。

リファクタリングでまず必要となるのが、クラス設計の見直しになります。

特に継承先のクラスで何度も使用する変数や処理は、継承元のクラスに移すことで、より洗練されたソースコードになります。

システムは、動作するものができたら終わりではありません。

定期的にソースコードをリファクタリングを行うことで、セキュリティ上の脆弱性を防ぐこともできます。

大きなシステムほど、過去のソースコードには手を加えないという暗黙の了解のあるプロジェクトがありますが、そのようなシステムは、スパゲティコードになっていることがよくあります。

まとめ

クラス設計書は、詳細設計の工程で作成される設計書ですが、何度もリファクタリングを行い、それに伴って改訂をしていきましょう。

クラス設計書があることで、新たな機能の追加や変更にも早い対応ができます。

また、クラス設計を行うツールも多く出ていて、クラス設計からソースコードを生成してくれくツールもありますので、用途に応じて探してみるのもいいかと思います。

では、今日はこの辺で。

良く使われるデザインパターンMVC

こんにちは。

今回は、よく使われるデザインパターンについて書いていきます。

結論から言うと、よく使われるデザインパターンは、「MVC」というデザインパターンです。

おそらく、ほとんどのシステム開発で採用されているのではないでしょうか。

私が携わったシステム開発は、ほとんどがMVCで開発を行っていました。

デザインパターン

デザインパターンとは、GoF の著書『オブジェクト指向における再利用のためのデザインパターン』で記した２３種類のパターンをいいます。

オブジェクト指向の良いところは、再利用可能であるということです。

再利用できるため、システム開発の生産性は上がるはずなのです。

別の機会に書こうと思いますが、実際は、生産性が上がらないことも良くある話です。

MVCは以下の頭文字です。

• Model（モデル）
• View（ビュー）
• Controller（コントローラ）

MVCは、良く使われるフレームワークで使用されており、MVCに分けて設計・製造することで、綺麗なソースコードとなります。

Model（モデル）

Modelは、データを扱うクラスです。

データベースを使っている場合は、テーブルごとにModelクラスを作成することが多いです。

フレームワークによって違うのですが、テーブルごとにModelクラスを作成することで、テーブルの外部キーを使用して、テーブルの連結を行うことができ便利です。

SQLを記載しデータを取得するのも、このModelクラスとなります。

View

Viewは、画面表示のクラスです。

Webシステムでは、ViewにHTMLなどが書かれます。

また、Webシステムでは、ViewはControllerから受け取ったデータをHTMLに取り込み、ブラウザへ渡します。

CSSやJavascriptは、Viewではなく別に管理されることが多いようです。

私の経験では、Viewは、動的な画面のHTMLに値を設定する処理を書いて、静的な画面のHTMLやCSS、Javascriptは、別のディレクトリで管理していました。

Controller

Controllerは、制御をするクラスです。

Webシステムの場合は、まずControllerクラスが呼び出されます。

ControllerからModelを呼び出し、画面表示に必要なデータをViewに渡す処理を行います。

フレームワークにもよりますが、Controllerから返すのは画面表示に必要なデータのみで、実際にViewでデータを埋め込むのは、フレームワークが処理することが多いです。

MVCパターンでビジネスロジックをどこに書くか

MVCのフレームワークを使用する時に良く起きる問題が、ビジネスロジックをどこに書くかです。

結論を言うと、私にも分かりません。

ビジネスロジックとは、実際の処理のことです。

例えば、ボタンを押して、データベースから値を取ってきて、加工して表示するとします。

1. ボタンを押して、Controllerへ処理がきます。
2. ControllerでModelを呼び出し、データベースからデータを取得します。
3. データを加工します。
4. Controllerがデータを返します。

上の処理だと、３の工程をControllerで行うかModelで行うかという問題です。

私の経験から言うと、半々くらいです。

ただし、ビジネスロジックが入るとソースコードが複雑になり、場合によってはソースコードが汚くなることがあります。

ビジネスロジックを書くクラスを作るプロジェクトもあるくらいです。

この問題は、プロジェクトに合わせて設計・製造するしかないと思います。

まとめ

フレームワークでは、良くMVCのデザインパターンが使われています。

そのため、これからプログラマーを目指すのでしたら、MVCを意識して勉強することで、実践で困ることも少ないのではないでしょうか。

では、今日はこの辺で。

プログラムの基本処理

こんにちは。

今日は、プログラムを学習するときに押さえておきたい点について書いていきます。

結論から言うと以下の処理を押さえておけば、プログラムを読むことはできるようになります。

• 分岐（if文）
• ループ（for文、while文）
• 関数

プログラムの基本処理

プログラムは、全てが四則演算でできています。

入力された値を変数に入れて、足したり、引いたりと加工し、出力した値を作り上げます。

私は、いろいろなプログラム言語で開発した経験があるのですが、コーディングを開始する前に、まず確認するのが、分岐、ループ、関数の書き方、呼び出し方です。

分岐（if文）

まず必ずと言って良いほど必要なのが「分岐（if文）」です。

条件によって処理を分岐することは必ず発生します。

Javascriptだと以下のような書き方になります。

if (<条件>) {
// 処理
}

分岐を理解するだけでも、プログラムは読めるようになります。

ループ（for文、while文）

同じ処理を繰り返し行う場合は、ループで処理します。

同じ処理を何度も書かないということは、不具合を減らすためにとても大切なことです。

Javascriptでは以下のように書きます。

for (<初期値> ;<条件> ; <加算> ) {
// 条件が不一致となるまで実行する処理
}

ちょっとわかり辛いですかね。

具体的なソースコードを書いておきます。

var a = 0;
for ( var i = 1 ; i < 5 ; i++) {
a = a + i;
}
// a = 10

a の初期値は０です。

i の初期値は１で、５より小さい値の間、i を１づつ加えて処理します。

つまり、a の値は以下のように変化します。

a = 0;

a = 1;     // i = 1

a = 3;     // i = 2

a = 6;     // i = 3

a = 10;   // i = 4

i は 5 まで変わりますが、条件に不一致となるので、ループを抜けます。

ループには、while文という処理もあります。

while文は、条件判定は処理した後に行う時によく使用します。

つまり、一度はループ内の処理を行った後条件を判定する場合です。

Javascriptでは以下のようになります。

do {

// 処理が不一致の場合に実行する処理

} while (<条件>);

while文で気を付けないといけないのは、条件の部分です。

while文は、条件が一致した場合にループを抜けます。

また、無限ループを作成し、処理内で分岐してループを抜ける場合もあります。

while(1) {

// 処理

if (<条件>) {

break;

}

}

ただ、このような書き方は、できるだけしない方がいいです。

できるだけ条件を入れて無限ループは作らないようにしましょう。

関数

最後に必要となるのは、関数です。

ループ処理でも書きましたが、同じ処理は何度も書くと不具合の原因となります。

同じ処理と何度も必要となる時は、関数にして呼び出すようにしましょう。

また、最近の書き方だと、１関数１処理で書くようにすると綺麗なソースコードになります。

Javascriptだと以下のような書き方になります。

function <関数名> (<引数>) {

// 処理

}

プログラミングの経験を積んだ方でも、処理を関数化せずにダラダラと書く方がいます。

そういうソースコードをスパゲティコードといいます。

処理が長くなって、少し修正するだけで不具合の原因となったりします。

まとめ

プログラムを読む際の基本となるのは、この３点です。

• 分岐
• ループ
• 関数

そして、後は多くのソースコードを読んで、処理の書き方や、綺麗なソースコードの書き方を学んでください。ソースコードは人によって書き方が違います。読むだけでも結構勉強になったりしますよ。

では、今日はこの辺で。

私がプログラマーでいる理由

こんにちは。

今日は、私がプログラマーをしている理由についてまとめてみます。

結論から言うと以下のようになります。

• 考えることが好きだから
• 楽しいから
• 喜んでもらえるから

私は、もう２０年ほどプログラムに携わっています。

はじめでプログラムを勉強したのは大学の時で、

授業でプログラムの講義を受講したのが初めてでした。

その時は、Basic言語を授業で勉強しましたが、

あまり興味は持ちませんでした。

その後、C言語の授業を受講し、

すでに研究室に入って研究の手伝いをしていた私は、

これは結果の整理に使えると思って自分で勉強するようになりました。

ちなみに、大学１年の後期の頃です。

考えることが好き

私は、いろいろな事を考えることが好きな方です。

どうやって動いているのだろう、どうやって利益を得ているのだろう。

プログラムを書いていても、

単にプログラムを書くだけてなく、

修正しやすくなるように、読みやすくなるように、美しくなるように、

と考えて書いています。

これを考えずに書かれたソースコードは、

動くのですが読みにくく、修正し辛いソースコードになってしまいます。

また、実は不具合が出やすいソースコードは、

何も考えずに動くことのみを目的として書かれています。

プログラミングを行うことは、基礎勉強が終わった方でもできます。

しかし、どうすれば読みやすく、修正しやすく、不具合の少ないソースコードになるかを考えてプログラミングするには、やはり経験が必要となります。

楽しい

私がプログラマーでいる理由は、これが一番です。

やはり、楽しくないと続けていられません。

また、IT業界は日進月歩で発展しています。

それに着いていくには、新しい技術の勉強が欠かせないのです。

勉強といっても、本を読んで勉強するのではなく、

これどうなってるのだろうと興味を持ってWebで調べ、

新しい技術を吸収しています。

この作業は、楽しく、好きでないと続きません。

たまに、どうやって勉強したらいいですか、と聞かれることがあるのですが、

正直勉強しているつもりはないので、勉強なんかしてないよとしか答えられません。

そんな方は、プログラマーと言う仕事を楽しんでないんだろうなと私は思っています。

喜んでもらえる

プログラマーの仕事は、お客様の期待に答える仕事でもあります。

なので、出来上がってお客様の作業が軽減されると喜んでもらえます。

もっとこうしたい、こういい機能も加えたいと言われると言うことは、

そのシステムが喜んでもらえている証拠だと思ってます。

ただ、無料でやってくれと言うお客様もよくいるのですが、

それはちょっと傲慢だなと思います。

喜んでもらえるのは嬉しいのですが、

やはりビジネスとしてプログラマーをやっている以上は、

作業にかかる代金は払ってもらえないとモチベーションも落ちてしまいます。

たまに、ソフトウェアは無料で使えると考えているお客様がいます。

同業者にも、有料ソフトウェアをライセンス料を払わずに使っている方もいます。

ビジネスとしてプログラマーをやっている側から言えば、

投資をして開発されたソフトウェアをライセンス料を払わずに使うのは、

窃盗に近いと考えています。

ソフトウェアを使うのであれば、

きちんとライセンス料を払いましょう。

まとめ

やはり、好きで楽しいことを仕事とすることが一番いいように思います。

楽しくないと、新しい情報を吸収しようと積極的に動けないし、

そもそも、情報が入ってきません。

楽しく働いていればストレスも、あまり溜まらずにすむのではないでしょうか。

では、今日はこの辺で。