- コンテスト作品10～19

作品10～作品19/全54作品

No.	model
10	つとむ san いろいろ追加したい気持ちを抑えてシンプルさを目指しました。 UMLの基本的な記述方法しか知らないので、これからMLで勉強させていただきます！
	Judge's comment <よい点> 　・シンプル　・クラスの配置がわかりやすい　・オブジェクト図の作り方にすぐ習熟している <気になる点> 　・ちょっとオブジェクトの抽出が足りないよう　・[トレンチコート：預かりもの]オブジェクトの処理が大きすぎないか　・多重度間違い(注文→顧客が、オブジェクト図では1..*) 　・料金表の扱いが変　・タグのモデル化が変　・料金表がお題を表現できていない　・サービス適用や料金計算の制約が表現できていない　・防虫加工の料金がどのように扱っているかわからない

11	ぼあろ san (株式会社エイブルコンピュータ) 料金の扱いに悩みました。
	Judge's comment <よい点> 　・とても良くまとまっている <気になる点> 　・品物の「返却可」の意味がわからない(オブジェクト図) 　・品物の「返却可」はきっと、状態なんでしょう。状態は概念レベルではクラスにした方が良い　・多重度の理解が変　・1..3という多重度は不適切(3つに限定するメリットがない) 　・複数個所の多重度が共通にもつ制約がうまく表現できていない　・品名は3つしかないのか　・チケットの本質的なところを捉えて欲しい

12	いっぺい san 注文→商品は、商品がなければ注文が成り立たないのでコンポジット、商品→加工は、商品は商品として成り立つので集約にしました。クリーニング屋さんからの視点で見ると、加工がない商品があると困るのでコンポジットかなと思います。品名（シャツとかコートなど）はあえてクラスにする必要はないと思い、属性にしました。 UMLやオブジェクト指向は独学で今まで誰にも相談したことがないので（できる人がいないので）、他の人のものと全然違いそうで不安です。。。
	Judge's comment <よい点> 　・シンプル <気になる点> 　・オブジェクト図の広がりが足らない　・オブジェクト図の文法が誤っている　・多重度が入ってない　・料金のルールを表現していない　・情報や制約を表現していない

13	たっちゃん san (株式会社ブレイニーワークス) モデリングをするとき、「まずオブジェクト図から考える」というアドバイスには目からウロコが落ちる思いでした。今回はタグの扱いをどうするか、結構、悩みました。分かりやすいモデリングになっていればいいのですが。。。また、OCLをつかった細かな制約条件の設定方法については、よく知りませんので、割愛しています。（同じ顧客のインスタンスとの関連として見て下さい。）
	Judge's comment <よい点> 　・来店クラスというネーミング、発想がよい。とてもよい <気になる点> 　・オブジェクト図の色分けが理解しづらい　・[識別]クラスがあることで、オブジェクト図と内容が違ってしまっている　・[オブジェクト図]はとてもうまく描けているのに、[クラス図]に変換する過程でおかしくなってしまっている　・識別クラスの意味がよくわからない　・サービスと防虫などのクラスの両方があることが理解しづらい　・来店とチケットなど概念がダブった冗長なクラスが多い　・識別クラスの汎化関係がよくわからない(文法的におかしい) 　・多重度がおかしい(「費用」が0の「クリーニング品の種類」？) 　・右下の部分(識別クラス周辺)がわからない　・タグの意味がよくわからない　・費用という名前のセンスがよくない

14	ケニーJ san (株式会社日本ビジネス開発) 問題を見て典型的な"注文明細"パターンの亜種だとアタリを付けモデリングしてみました。他の方と本質的な差がうまれにくいと感じたので、サービス料金の履歴対応付は考慮しました。最初アナパタの責任構造の様な期間の持ち方をしていましたが、オブジェクト図を書きながら問題点に気づき現在の形に落ち着きました(分析レベルですので。。)。また唐突に現われた「初クリーニング」は業務を確認した上での小さな揺さぶりの第一歩という趣で加えてみました。
	Judge's comment <よい点> 　・期間という拡張はよい　・オブジェクト図が広がっている　・色分けとノートで、わかりやすい　・サービスをうまく定義できている　・かなり常識的にまとまったモデル　・料金改定に関する対処は○ 　・「預かり明細」にある「点検メモ」という属性は◎ 　・メインの構造はシンプル <気になる点> 　・もうちょっとシンプルにできたのでは？　・オブジェクト図の配置にももうちょっと気を配って欲しい　・冗長ですよね。モデルに本質的なインパクトがないところで揺さぶってもしようがないと思う　・サービス種のPowertypeとしての取り扱いを勘違いしてしまっている　・預かり明細と適用サービスの意味がわかりづらい　・「品目」と「預かり明細」との間の関連の{導出}は派生関連の意味か… 　・「サービス」は「品目」と「サービス種」との関連クラスにしてしまった方が良かったような… 　・「サービス種」のサブクラスの存在意義が微妙？　・防虫加工の価格が品目に依存しないことが表現できていない　・預かり明細と品目間の関連は導出ではない

15	およよ san 料金をどのように持たせるか悩みました。あとはクラス図があっさりし過ぎかなと思っています。(分析不足か) 厳しい指摘がいただけたらと思います。
	Judge's comment <気になる点> 　・オブジェクト図がよみにくい　・オブジェクト図で、せっかく品種、サービスの具体例を挙げているのに、それをノートの中に書いておくだけというのは勿体ない　・サービスの意味がわかりにくい(サービスのインスタンスはなにを意味する？) 　・タグは適用サービスを表しているんですね。でも多重度が変　・多重度の間違い(サービス-料金は1:1だが、オブジェクト図の右端のクリーニング:サービスは違う) 　・品種クラスがサブクラスを持ってしまっている　・タグの関連がおかしいところがある　・継承で対処するのか、ロールで対処するのか、方針を明示すべき

16	Juca san 二回目の参加です。またギリギリの投稿になってしまいました。揺さぶり等含めて、コメント頂ければありがたいです！
	Judge's comment <よい点> 　・シンプルかつわかりやすい　・オブジェクト図がよく網羅されている <気になる点> 　・タグは不要　・タグの位置づけを誤解している　・預かり伝票（チケット）とクラスに2つの名前をつけている　・多重度が変　・料金が表現できていない　・料金の制約を表現できていない　・預かり品へのノートのいわんとする内容がわからない

17	fifty san 指摘いただいた料金の決定方法、店員クラスの存在意義を中心に手を入れてみました。
	Judge's comment <よい点> 　・オブジェクト図に気合が感じられる <気になる点> 　・ゴチャゴチャしている　・視点がおかしい、抽象化できていない　・料金「表」インタフェースの意味がわからない　・伝票が登場するが説明がない　・伝票はビュー。冗長。店員とかモデルの本質にインパクトのない要求は持ち込まないほうが良い　・料金表クラスの<<boundary>>がわからない　・クラス図の配置に一工夫欲しい。左から右に分割しているだけのように見える

18	やましょー san (株式会社菱友システムズ) 考え過ぎないように気をつけながら、シナリオから読み取れるものを中心にして書いてみました。
	Judge's comment <よい点> 　・シンプル　・本質を捉えようとしている　・ロールの使い方がうまい　・シンプル系のモデル群の中では一番良い　・記述された範囲では多重度などに誤りもなく、第1次近似として許容範囲 <気になる点> 　・依頼品のサブクラス化は不要　・料金の表現がない　・オーダーは適用サービス　・料金に関する制約を表現していない（のでシンプルになって当然という気はする）

19	若の里ファン san (株式会社メトロ) 何を汎化するか、汎化しないか。それが問題だ。簡単なようで、とても難しいですね。
	Judge's comment <よい点> 　・オブジェクト図を分けているのがよい　・整理できている <気になる点> 　・配置がよくない。とくに斜めの線が不安定　・メニューの意味がよくわからない　・メニューのような存在価値のないクラスが多い　・顧客が注文に対して依頼している、という関連の意図が汲み取れない　・2重に関連を冗長に張っているが意味を見出せない　・料金のもつ制約が表現できていない

コンテストに戻る

Sections

Personal tools

Navigation