Skip to content

Tag: pattern

パターン編(3) 分析・設計パターンの重要さと書籍紹介

当「モデリングしてますか」チャンネルの”パターン編”の意味、なぜパターンを知っておくことがよい­モデリングにつながるのかについて解説します。世の中には、ソフトウェア開発活動に役­立ついろんなカテゴリのパターンが存在します。分析パターン、設計パターン、実装パタ­ーン、アーキテクチャパターン、などなど。お薦めの書籍とともに紹介します。 [スクリプト] モデリングしてますか? 今日は、パターン編という事で、ソフトウェアのパターンの重要性について、最初にお話ししたいと思います。 パターンとは? パターンとは、歴史を話すと凄く長くなるので、今日は話しませんが、ソフトウェアの色々な開発活動の中で、よく行われている例(パターン)が、いくつもあって1つのパターンを形成します。こういう風にやるとうまくいくんだ、というものに名前をつけて、集めてくる手法です。 例えば、実装のコードレベルのパターンもあれば、設計レベルや、分析レベル、ビジネスレベルのパターンもあり、非常に広範囲に使われる言葉です。 パターンとは、「名前」と、「名前が使われる文脈」と、「解こうとしてる問題」があって、「解決」があります。 だから、「文脈」、「問題」、「解決」をセットにして名前を付けたもの、という言われ方をしますが、基本的にはコードのように、固い再利用ではなく、考え方や知識を再利用するフォーマットになります。 デザイン/設計/ビジネスで使用されるパターン 1番良く知られているのが、この「オブジェクト指向における再利用のためのデザインパターン」という、95年に書かれた本です。ソフトウェアの中で、パターンが非常に花開くきっかけとなった本です。この本が書かれる前に、James o. Coplienが「Advanced C++ Programming Styles and Idioms」という本の中で「イディオム」として、実装のパターンを解説しております。 それから、Kent Beckの「Smalltalk Best Practice Patterns」ですが、これも実装レベルのパターンとして、非常に有名です。後にKent Beckは、Java版に書き直して、「Implementation Patterns」という本に変えています。これは実装のパターンです。 それから、分析に入ると、1番有名な本としては、「アナリシスパターン―再利用可能なオブジェクトモデル」で、Martin Fowlerが書いた本です。この本は、分析レベルで現れるパターンについて、書かれており非常に分厚い本です。 おそらく、これが書かれるおおもとになったのは、インフォメーションエンジニアリングという言葉を作った、James Martinの「オブジェクト指向方法序説〈基盤編〉」です。James J. […]

パターン編(2) 顧客、注文、商品をつなぐ「モノ – コト – モノ」パターン

チェンジビジョン平鍋が「リソース系の顧客および商品、とイベント系の注文をつなぐパ­ターン」を易しく紹介します。 前回の「パターン編(1) 注文書を表現するヘッダー明細パターン 」の続きです。 モデリングしてますか? 前回は、ヘッダー明細パターンという事で、「注文」と、「注文明細」、もう少し詳しくいうと、このような「注文書」の中で、この「注文明細」と、全体の「注文」の関係について解説をしました。今回は、前回登場しなかった「商品」という概念について、今回は詳しくお話ししたいと思います。 「商品」という概念とは? ここには「注文明細」とありますが、注文の1行は、1つの商品と紐付いています。 そのため、「商品」という概念を登場させます。 このように注文明細の中にある「タオル」という注文に対して、「単価」「数量」「金額」がありますが、この「商品」をモデリングすると、このようになります。「商品名」と「定価」という風に、データ構造しておきます。 ここで、「単価」と「定価」は重なるのですが、場合によっては「定価」から値引きをする場合があるので、このような形にしておきます。「注文明細」から見ると、「商品」は1つと決まっていて「商品」から見ると、「注文」は複数対応する事があるというパターンになります。 「モノ – コト – モノ」パターン ここからが面白いんですが、両脇にある「顧客」と「商品」は割と長く存在しているものです。 「注文」とは、一時のものです。 このような「顧客」や「商品」の事を、「リソース」という言葉で表す事があります。 それから、「注文」は、寿命が長い2つのオブジェクト(リソース)の間にあって、一時のトランザクションを示すものを、「イベント」と呼ぶ事があります。このように2つのリソースを、結びつけて1つのイベントが起こるというパターンは、非常によく起こる事ですね。 ここをヘッダー明細パターンといいましたが、色々よび方がありますが、この事を、児玉さんは、「モノ – コト – モノ」パターンという非常に良い名前をつけています。 また、企業の情報システム構築のデータ構造では、このパターンは非常によく出てきます。 リソース2つがあって、真ん中にイベントがある。特徴は、イベントには必ず「日付」があるという事ですね。 それから、前回お話しできなかったのですが、この「注文明細」の合計が「注文」になります。そのため、「注文金額」というのは、実際には「注文明細」から掛け算して、足し合わせたものになるので、自動的に決まりますね。これを、「派生属性」と呼んで、斜線で表します。 応用がきくパターン まとめると、よく見る「注文書」とは、1つの注文の明細になっています。「件名」と「金額」が、1つの注文になっています。 […]

パターン編(1) 注文書を表現するヘッダー明細パターン

業務上非常によく出てくるパターンとして「ヘッダー明細」を取り上げます。基本編(1) まずはクラス図の「顧客ー注文」の先にあるものです。 [スクリプト] モデリングしてますか? このビデオシリーズ、パターン編の第1回目は、ヘッダー明細パターンというのを、やってみたいと思います。 このパターンは非常に、よく使われるので、色々な場面で出てきます。 「注文」のパターンを考える 今回は、前回基礎編でご説明した「クラス図」で出てきた、「顧客」やそれに対する「注文」がありましたね。 その「注文」を、詳しくみていきたいと思います。 前回の通り、「顧客」には「名前」と「メールアドレス」があって「注文」には、「日付」があり「金額」がありますね。 このような描き方になっていますが、一般的に、「注文」というのは複数の商品からなっていますよね。 「注文書」を思い浮かべてください。 よくビジネスで使われているので、皆さん、当然見た事があると思いますが、注文書には、お客さまの名前、件名があり、金額があります。メールアドレスや電話番号もあると思います。そして上部には、注文の日付がありますね。それから注文の番号があります。 次に、自分の会社の名前があって、下部には合計金額の内訳があります。内訳として、品名、単価、数量、金額があります。 つまり、この例でいくと、「ロゴマークデザイン」というデザイン料として単価が1万円、数量が1ケ、金額が1万円となり、「タオル」の単価が1000円が10ケで2万円となっています。それで、金額の欄を足したものが、合計の金額となっているわけです。 注文書をモデリングしてみる 非常によく出てくるフォーマットと思いますので、これをモデリングしてみたいと思います。 この「注文」の中に「金額」がありますが、「金額」の下をみていくと、1行1行クラスとして表現しています。 その1行の事を、「注文行」という事もありますし、「注文明細」と呼ぶ事もありますね。そこには、「単価」があって、「数量」があります。「注文」は、「注文明細」を保持していますよね。 もし「注文」がなくなれば、「注文明細」の意味が無くなるわけですから、正確に描くと、「注文」の多重度は1になります。 「注文」には、複数の「注文明細」があり、そして「注文明細」に「単価」と「数量」があり、これを掛け算したものが、1つの行の 商品に対する金額になります。 これを足し合わせたものが、注文全体の金額になるというパターンになっています。この強い保持している関係を、UMLでは「コンポジット」という黒い四角で表します。 このように全体があって、部分が行に分かれていて、それぞれの行の合計が、全体になっている、というのをヘッダー明細パターンと 呼んで、注文も、注文明細も、例えば見積もりや、売上に対して、このようなパターンが成り立ちます。 もう1度、先ほどの注文書で復習すると、1行1行書かれているものが、注文明細になるんですね。 「商品」という概念があって、「商品」との関係を描くことによってもう少し注文書全体を、細かくみていきたいと思います。 まとめ このようなUMLを使ったパターンは、多く本が出ていますので、また次回紹介したいと思います。 例えば、細川さんが書かれた、「UMLによる一気通貫DBシステム設計 […]