|
Javaでショッピングカートの講習
アンコールにお応えして、ほぼ1年ぶり(長らくお待たせしましたが)、
Java初級者に大好評だった講習を再び実施します。 小さなJavaプログラムは自由に作ることができる。 でも、例えばショッピングカートのように、 ちょっと複雑になると、思うように作ることができない。 アナタが、そういう状況なら、原因はおそらく プログラム設計力が不足してます。 「えっ?!設計はセンスが無いから無理」って? いやいや、違います。 「設計はセンス」と言う人もいますが、 漠然としたシステム要件の本質を捉えて、 機械的に設計図を描く方法があるのです。 本当に必要な設計図とは何か? 設計はUMLで表記します Javaはオブジェクト指向の言語です。これはいいですね。 で、オブジェクト指向開発の設計図を描くにあたって、一般的には、 UMLという表記方法が用いられています。 まあ、その昔は、色んな表記方法があって百家争鳴状態だったのですが、 20世紀の終わりごろにMicroSoft、IBM、OracleがUMLを認めることで、事実上 UMLが標準の設計表記方法となりました。 まあ、UMLの詳細はググって頂くとして、 少なくとも今、「UMLが標準」は既成事実となっています。 UMLは、とにかく設計図や表記方法が多いです で、そのUMLですが、とにかく設計図や表記方法が多いです。 まあ、とっても頭のいい3人が必死に考え出しただけあって、 こんな場合も、こんな場合も、こんな場合も・・・・・・と色々な場面を想定して、 漏れなく色んな設計図を出し尽くしています(これは、これで素晴らしい)。 例えば、↓のような感じで設計図があります。
資料作りのための設計図・・・・ UMLには、このように色々な設計図がありますが、当然ですが、 設計図はプログラムを作るための設計図であるべきです。 と(心あるSEは)思っているのですが、まあ会社の決まりや、なんやらで、 設計図=資料づくり(上司のための) みたいな図式で、 資料作りの一環として設計図が描かれると、変なことになるんですね。 全てを設計図にして混乱が始まる 例えば、以前、私が参加したプロジェクトでは、要件定義の後、2ヶ月もかけて、 ユースケースの全てをシーケンス図に落としたり、 登場するクラスを全て無理やりクラス図にしたり、 プログラム作りに関係の無いコラボレーション図や状態図を作ったり、 そんなことばかりやってました。 確かに資料としては意味があるのかもしれませんが、でも正直、 プログラム作りに参考にする設計図は、その 一部でしかありません。 結局、後から見ると、あれだけ苦労して作った資料(設計図)なのに、ソースとの矛盾だらけで、 「設計図よりソースを見てください」みたないバカバカしい状況になってしまいました。トホホ・・・ プログラム作りに参考にする設計図とは? でね、 私がここで述べたいのは、そういう無駄な設計図の話でなくて (すみません、前置きが長くて)、 プログラム作りに参考になる設計図とは一体何なのか? その設計図を作るためには、どうすればいいのか? そういう本質的なお話をしたいのです。 結論を(誤解を恐れずに)言えば、まずもって、 本当に必要な設計図は、以下の二つです。 ・クラス図 ・シーケンス図 この結論は私が現場で感じることですし、 他の技術者も言っているし、ネットで調べてもそうだし、 まず間違いありません。 ユースケース図は、お絵かきか? 「おいおい、ちょっと待てよ。ユースケース図はどうするんだ?」 とアナタは思うかもしれませんね。 そうなんですよね。UML的順序からいくと、 ユースケース図→クラス図、シーケンス図 となるのですが・・・・・ まあ、「ショッピングカート」システムを例にして、一応、 ユースケース図を描いてみると、↓のような感じになりますね。 ![]() 確かに簡単に描けるけど、問題は、 ここから直接(機械的に)、クラス図やシーケンス図に繋がらないということなんです。 実際、 「ユースケース図ねえ、単なるお絵かきでしょ」「わかりやすいけど、意味無いね」 という技術者が多いんですよ。 オブジェクトと登場人物(アクター)の関係図が有効 ユースケース図の問題点は、「対象となるモノ」が出てこないことです。 文法的に言うと、主語と述語はあるけど、目的語が無い、そういう状態なんです。 だから、後々の設計図に繋がらない。そう思います。 と、批判ばかりしていても建設的でありませんので、 「じゃあ、どうするのか?」というところを話しましょう。 私は、(ユースケース図を発展させたような) 関係図が有効だと思っています。その関係図には、目的となるモノを加えます。 例えば、ショッピングカートのシステムを作ろうとしたとき、 お客さんからは、以下のような要件が(漠然と)出てきますね。 ----------------------要件----------------------- 「店主」と「ユーザー」がいて、 「店主」は、商品登録ができて、登録した商品は一覧にできて、 ユーザーは、商品一覧から選択購入できて、 ショッピングカートは、商品の合計金額が計算できて・・・・・ ------------------------------------------------- まず(ユースケース図と同様に)、 登場人物「店主」と「ユーザー」をアクターと言って、人間マークで記述します。 で、「○○できて」という部分を矢印にして、 モノを長方形でオブジェクトに見立てる。 そんな感じで、お客さんと話していくと、 「ショッピングカート」なら、↓のような関係図を作れます。 ![]() まあ、これだったら 少々の慣れですぐにできるし、 直感的にもわかりやすいですね。 で、とっても重要なのですが、さらにこの関係図から、 機械的に シーケンス図とクラス図ができます。 そう、ここが大切です。 この関係図から、シーケンス図とクラス図ができるのです。 ほぼ機械的に。 例えば、この関係図だったら、すぐに、 ああ、シーケンス図は○本描いて、 クラス図は、○○の機能を継承して重複を避けて、○○で利用する・・・・ ※○○が伏字なのは、ご了承ください。 と、すぐに設計図を描いてしまう。 あ、もちろん、その設計図(クラス図、シーケンス図)から、 すぐにプログラムソースを書き始めることができます。 どこかの資料のための設計図とは違いますので。 たった75分、一緒にやってみませんか 要件→設計図→プログラム、こういうスムーズな流れ、これこそ Java初級者が本当に設計を学ぶ第一歩だと思います。 会社の資料作りは二の次でいいでしょう。どうせ使わないし。 そこで、今回はショッピングカートを題材にして、 要件→設計図→プログラムという本質的な流れを学ぶための、 講習を行うことにしました。 もちろん、アナタもお忙しいことでしょうから、 私が、効率的に本当のエッセンスだけを学べるように工夫して講習は作ってあります。 興味がある場合は、どうぞ続きをお読みくださいね。 講習の具体的内容 ショッピングカートのサンプルは私が提供します ショッピングカートのサンプルは、私のほうで提供します。 実際の動きを見ることもできるし、サンプルを見ないでソースを作って、 答えあわせのような感じで使ってもらってもOKです。 もちろん、作業方法は全て図解しています。 ![]() ちなみに、こちらがショッピングカートの動きです ちなみに、こちらが、その画面です。 ↓で、商品にチェックすると、 ![]() ↓のように、合計金額が出てくるわけです。 ![]() 何故、ショッピングカートは、 中身を覚えていて、合計を計算できるのか? 答えは簡単です。 あたかも現実世界のように、「ショッピングカート」というオブジェクトを作って、 そこに購入商品を入れているからです。 では、具体的には、どうやって設計しプログラムになるのか?その仕組みは? 講習でしっかりと解説していきましょう。 クラス図をどうやって作る? クラス図は、関係図のある部分に注目して作成します。 その、「ある部分」とは何か?もちろん講習で詳しく解説します。 具体的には、 ↓のようなクラス図(の原形)が出来上がる過程を学んでいただきます ![]() シーケンス図はどうやって作る? 次は、シーケンス図です。シーケンス図もミソがあります。 そのミソさえ知っていれば、○本のシーケンス図が必要で、 そこに何を描けばいいのかがわかるのです。 もちろん講習で解説するので、 一緒にシーケンス図↓を描いていきましょう。 ![]() クラス図とシーケンス図から、 どうやってプログラムを書くのか? 当然ですが、次のステップとしてクラス図とシーケンス図から どうやってプログラムソースを書くのか?という話をしていきます。 (資料的な設計図を描いていると)そもそも クラス図とシーケンス図の住み分けもできてないことが多いので、ソースもゴチャゴチャしますが、 今回の私の講習で、クラス図とシーケンス図のキモが理解できれば、 ソースへの移行が驚くほどスッキリする、ということが実感できると思います。 どうぞ、存分に設計図からソースを作るという作業を満喫してくださいね。 ![]() 以上のような講習内容で、 ショッピングカートの作成を通じて、 要件→設計図→プログラムソース作成 の全過程を体験して頂きます。 一緒に勉強してみましょう。 ただ、以下のような場合は、講習をご遠慮ください。すみません。 今回の講習対象外の方 Javaの開発環境が準備出来ない方 今回の講習では、当然ですがJavaを使います。 「Javaのプログラムを書ける」という必要はありませんが、 少なくとも、Javaの開発環境が無いと話になりません。 Javaの開発環境とは、 JDK、Eclipse、TomcatがあなたのPCにインストールされている状態です。 最新版でなくともかまいません。 Javaの開発環境が無い場合は、こちらから準備してください。 1〜2時間くらいで準備できます。 http://www.searchman.info/java_eclipse/1000.html 上記サイトをみても、 Java開発環境が準備出来ない場合は、今回は受講しない方がよいかと思います。 Javaの設計に詳しい方 あくまでも、要件→設計図→プログラムソースがスムーズに出来ない、 と感じる方のみ、ご参加ください。 ですので、 UMLを使いこなし、Javaの設計は楽勝、という方も今回の講習は必要ありません。 もし何かあれば、私が全て答えます 今回の講習も、例によって、私のテキストに従って勉強を進めていきます。 もしかすると、何かの理由でエラーが発生したり、 講習がうまく進まない場合もあるでしょう(滅多にないですが)。 そんな場合は、全て私が直接お答えいたします。 そのために、受講者専用の質問掲示板もご用意いたしました。 ですので、どんな下らないことも、 質問していただければ答えが出て前に進めるようになっています。 アナタはエラー、トラブル、意味不明、そんなことで悩むことがありません。 今回の講習で行わないこと あっ、断っておきますが、今回の講習では 「Java基礎文法」 「JspとServletの基礎」 「UMLの正しい表記方法」 「UML技術者認定精度の試験対策」 は扱いませんので、ご注意ください。 あくまで、ショッピングカートを題材として、 要件→設計図→プログラムソースが、 実際にはどのような流れていくのか、が主な話になります。 以上、今回の講習の特徴を述べてきましたが、申込みから受講までの流れも説明しておきましょう。 講習の申込みから、受講までの流れ <講習は、メールとホームページで行います> 今回の講習は、基本的に全てメールとホームページ上で行います。講習を申込みされると、メールで「講習専用サイト」をご案内いたします。アナタは、そのサイトをご覧頂き、講習を受講していただきます。<申込みの翌日から、メールが5日間連続で届きます> 講習申込み翌日から、講習メールが5日間配信されます。メールには、その日の講習の要点が書いてありますので、その要点を参考にして専用サイトでの学習を行ってください。講習メールとサイトの内容は、1日15分程度で済むように工夫してあります。時間が無いアナタにとっても、必ず効率よく勉強できるように設計してあります。 <合計75分間の講習です> 1日15分程度のメールが5日間配信されますので、合計75分です。毎日15分づつ講習を受けて頂いてもOKですが、まとめて75分受けて頂いてもOKです。アナタの生活パターンにあわせて受講してください。<迷った場合は、すぐに質問できます> 講習中に質問したいことがある場合は、いつでも受講者専用掲示板に質問することができます。私は、その掲示板を毎日チェックしていますので、最低でも1日〜2日後には回答を見ることができます。<質問期間は、来月末までになります> 講習申込み後、私と一緒に勉強して頂きますが、質問期間は来月末までになります。その間は、何回でも質問してください。そして、是非、この講習を使いこなしてください。さらに、 受講者の声もお聞きください
以上のような講習になります。私は、アナタにとって役に立つ講習になると思います。 しかし、最終的に 役に立つかどうかを決めるのは、アナタです。 (もし、アナタの役に立たないのに、講習費をいただくのは、私の本意ではありません。) 従って、この講習は、 6ヶ月の完全返金保証を行います。 6ヶ月間、いつでも返金要求できます。 ただし、カード決済の場合は、手数料がありますので1割手数料負担ください。 銀行決済の場合は、全額完全返金いたします。 返金要求方法は簡単です。アナタが 気にいらない場合は、申込されるとメールが届きますので、 そのまま返金要求してください。 謹んで返金させていただきます。 次に申込み締切日と、お申込みについてのお話です。 申込み締切日:2008年6月1日 Javaでショッピングカートの講習 (返金保証あり、質問は1ヶ月間何回でも受付て全て回答します)という条件で、 講習費は、4,000円です。 早く申し込むほど、質問期間が長いので、お得です。 イマスグお申込みください。 お申し込みはこちらです。 カード決済なので、すぐにダウンロードすることができます。 追伸 設計図は、アナタの頭を整理する過程である まあ、簡単なロジックなら、 設計図無しでソースを書けばいい。 でも、複雑なロジックになったら、 頭を整理して効率的にソースを書くために、設計図が必要になる。 繰り返しになりますが、一番の目的は、そこです。 「資料として必要だから」とか、「後々、困るから」とか、会社的に言うと、 確かにそういう理由もあるでしょうが、 この講習は違います。 複雑なロジックをプログラムソースにするにあたって、 その武器となる、 実践的な設計図の描き方を学ぶ そういうことをテーマにして、今回の講習を作ってみました。 アナタが、そういう必要最低限の武器を手に入れて、 今後の仕事に備えていただけたら、私も望外の喜びです。 きっと本物の技術力が身につき、どこにいっても通用します。 講習では、私も全力で頑張ってみます。 是非、一緒に勉強してみましょう。 どうぞ、よろしくお願いします。 ありがとうございました。 サーチマン佐藤 |