会話の背景：
帳票の設計と作成は、多くのソフトウェア工学の教科書ではあまりろんじられていない。現実では、特に日本の開発現場では、帳票の設計と作成に関する工数が大きく影響し、苦労することも多い。
帳票の設計と作成の重点は現場で使えるものとして、その実用性と便利さにある。そのため、現在すでに使っている手書き帳票や、システムの画面などをよく調べ、その上で設計した帳票サンプルを使って、早めにユーザーと調整することが大事である。
登場人物：
鈴木― ＰＬ
山田、田中― ＰＧ
会話：
鈴木：おはようございます。
前回の画面設計の検討に続いて、今日のミーティングでは帳票設計と作成の方（ほう）も本格的な検討に入りたいと思います。
山田：われわれが今回作る販売システムは、この前聞いた話では、これから管理を電子化し、”ペーパーレス”が目的と理解していますが、紙ベースの帳票はまだ必要でしょうか？
鈴木：そうですね。最近のメディアでは、”ペーパレス”とよく言われていますが、実はいくら電子化しても、実際には紙の使用量が増えていることが報告されています。少なくても、われわれのこのシステムでは、現場で今、使っている帳票のほとんどを出力することが必要になりまる。
具体的にいうと、領収書、請求書、注文書、納品書などはフォーマット通りにきちんときれいに出力できないといけないでしょう。このような帳票設計と作成に関する作業が全体の工数には大きく影響しますし、苦労することも多いと思います。
山田：そうですか。それでしたら、われわれがどうしたらいいでしょうか？
鈴木：まずは、皆にユーザーの現場で今使われている帳票のサンプルを集めるからはじめてもらいたいです。業務上（じょう）では、紙ベースの領収書、請求書、注文書、納品書などがあると思います。また、管理の面から見ると、売り上げの集計や販売実績の一覧などの管理系の帳票も紙への出力が必要なので、それらのサンプルもほしいですね。
山田：私が思うのは、サンプルを集めたら、一覧を作成し、重要度を付けます。その上で、各種類の帳票に関して、今回はそのまま出力するか？いらなくなるか？修正があるか？などを記述した上、ユーザーともう一度打ち合わせて進めて行くというのは、どうでしょうか？
鈴木：そうです。その通りですね。
それと、更に、各種類の帳票がどこのユースケースとつながり、またどこで出力するかなども記述しなければなりません。
田中：画面上での照会などの結果も出力して、帳票の一部として取り扱いますか？
鈴木：そうです。ただし、画面上で表現すると、画面おサイズの問題があり、またスクロールのこともあり、そのまま出力するとまずいかもしれません。やはり各出力に必要な画面に対して、ちゃんと帳票を設計しておいて、特別な工夫が必要だと思います。
田中：わかりました。
それと、出力のフォーマットはなんでしょうか？
鈴木：今回のお客さんがオープンソースソフトウェアに興味があり、ＰＤＦの出力であればいいといわれましたので、基本的にはＰＤＦで出力します。
ただし、一部の出力はExcelになるケースもあると聞きましたので、これは注意を払って、慎重に調査してから対応しなければなりません。この件に関しては山田君にお願いしたいのですけど、どうでしょうか？
山田：わかりました。調査します。ところで、出力のためのデータに関しては、今データベース設計もできていないため、どうすればいいでしょうか？
鈴木：そうですね。帳票設計と作成は実は長期的な作業です。まずは、われわれが必要な帳票などを設計しておきましょう。この設計はこれからのデータベース設計の参考にもなりますから。本番の帳票作成は、コーディングの一部として作業します。勿論その時も帳票設計の微調整があると思います。
山田：そうなると、時間がかかりますね。帳票設計や作成にかんするツールはありますか？
鈴木：帳票設計や作成に関するツールがたくさんはないですが、調べればかならずあると思います。たとえば、Jreportなど。とくにPDF出力に関しては、いくつか見たことの記憶があるので、田中君、調べてもらえます？
田中：はい、調べてみます。
鈴木：帳票設計や作成には、ツールがあっても工数がかかることに注意しなければなりません。大抵帳票設計がいくら綺麗にできても、実際的なデータを入れて出力しないと結果はわかりません。効果がぜんぜん違うことがしばしばありますから。そのため、やはり空の帳票だけでテストしてはいけません。必ず実際の、あるいは、現場で使っているデータにちがい数字によりテストすることが必要です。
そうしたら、山田君にはユーザーの帳票を集めて、さらにEXCELフォーマットの出力可能性についても調べてもらいます。田中君は帳票設計と作成ツール、まずはPDFに関するツールを調査してください。よろしくお願いします。それらができたら、われわれは再びミーティングを開いて、帳票の詳細設計と作成作業に関して議論しましょう。それでは、今日の会議はここまでです。みなさん、お疲れ様でした。
皆：お疲れ様でした。
１０．クラス図を書く
会話の背景：
ここにきて、やっと詳細設計に入る。
オブジェクト指向技術をベースにした開発する場合は、クラス図は詳細設計のベースとして位置づけられる。クラス図では、モデリング標準のUMLに従って、クラスおよびそれらの関係を表現し、各クラスの主な属性や操作などを記述する。
登場人物：
近藤―SA
鈴木―PL
山田、田中―PG
会話：
鈴木：こんにちは。今週から詳細設計に入ります。予定としてはクラス図、シーケンス図、状態図、それとデータベース設計を中心に作業してほしいです。今日は近藤さんにクラス図の作成方法などを説明してもらいます。それでは、近藤さん、よろしくお願いします。
近藤：承知しました。ここ数年前から、オブジェクト指向やUMLなどはすでに分析設計の常識になってきました。説明するため、まずUMLについてちょっと触れたいです。UMLとはUnified Modeling Languageの略称で、言い換えると統一モデリング言語です。
山田：そすると、UMLはすでに国際標準になっているわけですか？
近藤：そう言っても間違えないと思います。20世紀末の90年代にはたくさんのモデリング提案が出まして、その後Booch,RumbaughとJacobsonの三人がその揃って、統合的なUMLを提案が出まして、その後Booch、RumbaughとJacobsonの三人が揃って、統合的なUMLを提案した。この提案はOMGが1997に発表しました。いま、UMLは単に設計モデリングだけではなく、プロセスの定義言語、テストのフレームワークなどさまざまな分野へ展開しています。
田中：私もこの前ひとつのUMLコースを勉強しましたが、UMLとは、単に設計図を書く記号にすぎないと感じましたけど。
近藤：UMLはもちろん設計図を書く記号ですが、しかし設計の意図を正しく、正確に伝えるため、やはりこの記号の後ろにあるオブジェクト指向技術をマスタ－しなければなりません。
田中：これはクラスとオブジェクトのことを指しますか？
近藤：そうです。
本質的なのはオブジェクト指向の考え方です。オブジェクトというのは、現実的なものをコンピューター世界へ反映させた表現です。例えば、現実には車両があり、われわれのシステムではCarというオブジェクトで表現します。また、車両販売管理の現場では見積があり、システムではそれに対応したQuotationオブジェクトが存在します。
山田：それならば、このQuotationオブジェクトは現場での見積もり情報の集まりでしょうか？
近藤：そうともいえますが、それは、オブジェクトのある一つの側面です。オブジェクトとはデータを持つだけではなく、振る舞いも持ちます。データと振る舞いを統合することはオブジェクトの特徴ですね。
山田：なるほど。今回のクラス図はデータと振る舞いのどちらを表現するのでしょうか？
近藤：UMLでモデリングするには大きくわけると二種類のモデリングがあります。すなわち、静的なあるいはStaticなモデリングと動的なあるいはDynamicなモデリングがあります。今日話したいクラス図は静的なモデリングの一種です。クラス図は主にクラスの名前、属性、および操作を定義し、そのクラス間の関係付けを記述します。
田中：クラスの関係は複雑でしょうか？
近藤：そうでもありません。クラスの関係は大きく分類すると、継承関係、集約関係、それと関連関係という三種類があると思います。
継承関係とは基本的には同じタイプのものに対して、汎化性を抽出し、スーパークラスに定義します。特殊性はサブクラスになり、スーパークラスの持っている属性と操作を継承しながら、特別な属性や操作を記述します。
田中：それで、集約関係と関連関係の区別はなんでしょうか？
近藤：まず、関連関係とは、単にオブジェクトの関係をクラスレベルで表現したのもです。例えば、PersonというクラスとCarというクラスとの間には、「運転する」という関係があります。集約関係は関連関係の特殊なものともいえます。詳しく言うと、部品を表すクラスと、それを用（もち）いて組み立てられるクラスとの関係です。集約関係の特徴は、部品側オブジェクトが組み立て側オブジェクトに依存することです。
鈴木：例をあげると、自動車（car）というクラスがあって、一般的には自動車ですが、日産社製自動車（NissanCar)とToyota社製自動車はそれぞれ自動車（Car)継承関係を持ちます。自動車クラスが見積クラスや注文クラスとは関係を持っています。それと、自動車とタイヤクラスは関連関係ともいえますが、依存関係がありそうなので、集約関係を持つことも考えいられます。このような考えはよろしいでしょうか？
近藤：なかなかいい例ですね。
分析の初期には、一つは継承関係の定義を慎重に使ったほうがいいと思います。なんでもかんでも継承関係を付けることはいけませんね。また深い継承関係もさけてくささい。二つ目は関連関係が集約関係かなどを悩む必要はありません。もしはっきりわからなければ、とりあえず関連関係でもいいですから。属性や操作を定義しながらわかってくると思います。
最後に言いたいことは、クラス図を書くときには、システムが大きすぎると一枚の紙で書き切れないこともよくありますから、クラスをグルーピングすることが必要です。
われわれが今回開発しようとする車両販売管理システムの場合は、いまのところのユースケースやコンセプト図を読むと、大体60個以上のクラスがあると思います。そうすると、おそらく三つまたは四つぐらいのグループに分割すればいいと思います。
鈴木：そうですね。確かにグルーピングすることが必要ですね。わたしのイメージでは、例えば車両や部品などのクラスは品物のグループで、お客さん、メーカー、商社、営業マンなどは組織のグループになると思います。最後は、請求書、納品書、注文書などのクラスはまた一つのドキュメントグループになるかもしれません。
田中：わかりました。
鈴木：それでは、今日のミーティングはここまでです。近藤さん、どうもありがとうございました。皆さん、ありがとうございました。
皆：ありがとうございました。
没有评论:
发表评论