設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/09/29(金) 01:10:55.23

・要求設計、概念設計、論理設計、物理設計までを扱う範囲とします。

**デフォルトの名無しさん** · 2017/09/29(金) 01:29:23.55

%%%3%%%
000-DOK<NAZE-0.8112162>
001-3800%\73NMB/1,81,2,NB"IKKI"%
002-91.81%ML7"8.122231746668193,43@ML.4@"%^23.1444
003-1.33321444718%"YLD""SO"%{71.%{62.1339816{331.422231765%<<<NL6
004-LOOP%Go To"000"%

VCL

**デフォルトの名無しさん** · 2017/09/29(金) 03:11:51.92

テーマが漠然としてる
良い設計はどういう設計かとか
なんか問題意識が欲しい

あと具体的な題材も欲しい
図書館やレンタルビデオの
貸出管理をどう設計するかとか

**【お題】** · 2017/09/29(金) 03:55:44.00

・じゃあお題を建てよう。

・みんな>>3 を基準にして色々と考えてくれ。
・このお題が気に入らない場合棄却してくれても構わないが、
　その場合代わりのお題はつくってくれよな。

・「Excelに記録されているデータを読み込んで特徴を分析し、
それを洗練して互換的に格納するDBを作成るSQL案を自動生成する。
　　このシステムはデータをもとに推測を行って、テーブル作成から
　　データ流し込みまでの全てのSQL案を生成してくれる。
DB名, テーブル名, カラム名, データ型, 各種制約も出来る限り
　　頑張って設定してくれる。(わからない場合デフォルトの名前とか
　　が入るようになる。)
推測のしかたについて、オプション指定機能が搭載されていて、
オプション次第で様々なDB格納法が自動生成できる。
　　制約については何故その制約が必要と判断したのかの理由を
　　レポートしてくれる。」

**デフォルトの名無しさん** · 2017/09/29(金) 08:11:49.51

>>1
すみません、デザパタってなんですか？
まさかデザインパターンのことですか？？

**デフォルトの名無しさん** · 2017/09/29(金) 22:32:09.38

>>5
そうだよ、アナリシスパターンでもいいよ

**デフォルトの名無しさん** · 2017/09/29(金) 23:06:17.17

>>4
設計思想について話したかったんじゃないの？

**デフォルトの名無しさん** · 2017/09/29(金) 23:10:07.53

設計なんで実装の話は原則禁止

どの言語でも通用する話をするべき

**デフォルトの名無しさん** · 2017/09/29(金) 23:10:37.66

>>4
設計の話なんで、ExcelとかSQLとか言う話はいらない。
抽象化して書いてくれ

**デフォルトの名無しさん** · 2017/09/29(金) 23:18:03.15

いや俺が書いてあげよう。ExcelやSQLという言葉を消すだけだが

・「マイグレーションファイルに記述した定義から
いろんなデータベースにスキーマと初期データを自動生成する。
　　このフレームワークは初期データファイルから
　　データの流し込みを行ってくれる
スキーマや制約も出来る限り
　　頑張って設定してくれる。(わからない場合デフォルトの名前とか
　　が入るようになる。)
オプション指定機能が搭載されていて、
オプション次第で多くのDBMSに対応できる。
　　ER図とかの自動生成機能も存在する」

つまりRailsのようなものだ。

Railsを設計してくれという話だ。

**デフォルトの名無しさん** · 2017/09/29(金) 23:23:08.13

>>9
そこに出てくるExcel・SQL・DBは
みんな要件レベルの話で実装の話じゃないよ

**デフォルトの名無しさん** · 2017/09/29(金) 23:24:44.32

つまりは>>4はActiveRecordの設計がどうなっているか？
ORMとはどのような設計になっているかという話がしたいということだろう。

ORMとはデータベースをオブジェクトにマッピングしてくれるものだ。
というのはよく言われる簡単な説明の一つだな。

まず二次元のデータベースっていうのは慣れると単純なので
ある意味楽ではあるが、現実世界は二次元のデータには収まらない

初心者が勘違いしてしまうのはORMは単なるSQL生成ツールだと
思ってしまうこと。まあそれは本当の初心者だろうが、
ORMは複数のテーブルがあってそれぞれがつながってる
データベース全体をオブジェクトの形で表現するもの。

テーブル＝モデルと考えてしまうと、ある地点で行き詰まってしまう。
データベース＝モデル群と考えるのが正解。

データベースに入っているデータをいろんな視点（＝モデル）から
見ることができるようにするのがORM

だからORMを使う時にモデルとモデルのつながりの定義を書くのは必須なのである
（もちろんログや設定のようなつながりを持たないモデルもあるにはあるが）

**デフォルトの名無しさん** · 2017/09/29(金) 23:25:13.78

>>11
設計の話なんで要件の話はいらない。

設計の話をしましょう。
ActiveRecordとかね

**デフォルトの名無しさん** · 2017/09/29(金) 23:29:12.39

ActiveRecordはRailsが有名になったせいで
Rails特有のライブラリや概念だと勘違いしている人も
いるかもしれないがそれは違う。

ぐぐればすぐに分かることだが

http://www.techscore.com/tech/Ruby/Rails/other/designpattern/1/

> 1. Active Recordパターンとは？
>
> Martin Fowler氏の Patterns of Enterprise Application Architecture （邦訳）で
> 解説されているデザインパターンのひとつで、以下のように解説されています。
>
> データベーステーブルまたはビューの行をラップし、データベースアクセスを
> カプセル化してデータにドメインロジックを追加するオブジェクト

日本語訳は残念との噂が高いが、この本のこと

エンタープライズアプリケーションアーキテクチャパターン
https://www.amazon.co.jp/dp/B01B5MX2O2

なのでActiveRecordパターンの話は
あきらかに設計思想の話であると明確にしておこう

**【お題】** · 2017/09/29(金) 23:30:29.00

>>10
いいやそれは違う。
マイグレーションファイル書かないとだめじゃん。
SQLという文言は排除してもいいがExcelは排除したくない。

「IT全然知らない人がつくった.xlsxファイルを、データベースに入れたい」
「それと同時にデータベースをつくってくれる呪文」も手に入れたい。

RailsとかORMとか ActiveRecordとかもっと詳細化された概念じゃん。

**デフォルトの名無しさん** · 2017/09/29(金) 23:33:41.73

ActiveRecordパターン等のパーシステンス層アーキテクチャパターン
には次のようなものが有る

http://otndnld.oracle.co.jp/columns/arai-semi/data_access/2/

> Table Data Gateway
> Row Data Gateway
> Active Record
> Data Mapper

**デフォルトの名無しさん** · 2017/09/29(金) 23:35:53.60

>>15
> Excelは排除したくない。

お前の都合は知らん。

一番シンプルでわかりやすく強力な手段を選ぶべき

例えば、booleanと書けばいいのに真偽値と日本語で書くようなもの。
not null と書けばいいのに必須と日本語で書くようなことに意味はない
その考えで行くとExcelは排除すべきという結論になる

そのことを説明してもいいが、そもそも設計の話とは無関係なので
Excelの話はここでもう終わり

お前風言うのであれば

「Excelは排除したい」だ。このスレから

**デフォルトの名無しさん** · 2017/09/29(金) 23:36:19.09

仕様が確定してれば設計なんて猿でもできる
仕様が不確定な問題を設計までもってくる馬鹿がいるとその開発は失敗と思っていい

**デフォルトの名無しさん** · 2017/09/29(金) 23:37:47.81

一人で設計とは関係ないエクセルがーって
話をしたいならどうぞご勝手にとしか言うつもりはない。

ただ設計思想とは全く関係ないということだ。
だから設計思想の話をしたいと思ってる人は
俺を始め、エクセルの話は誰もしないということは受け入れろ。

**デフォルトの名無しさん** · 2017/09/29(金) 23:38:23.39

>>18
> 仕様が確定してれば設計なんて猿でもできる

それができる猿は見たこと無いので
説得力ゼロだよ。

**デフォルトの名無しさん** · 2017/09/29(金) 23:40:19.76

設計思想の話に戻ろう

といっても俺が何やら言うよりもまずはコピペでいいあろう。
設計思想の話について、何か意見があればどうぞということだ。

Active Record
３つ目はActive Recordです。一言で言うと「データベースのテーブル/ビューの
１つの行をラップしたオブジェクトで、データアクセスロジックやドメインロジックを
カプセル化したオブジェクトとして実装」といえるかと思います。

Active Recordは、それ自身にドメインロジックを含むという点でドメイン層の
Domain Modelパターンとデータベースのテーブルのレコードを表すという点で
パーシステンス層のRow Data Gatewayパターンに良く似ています。

まず、Domain Modelと似ているという点ですが、Active Record自体が
Domain Objectと成り得るのですが、本当？のDomain Objectと異なる点は、
Active Recordはテーブルの構造を元にして基本的にテーブルの列の表現として設計される点です。
一方、Domain Objectは、テーブルの構造に関係なく、オブジェクト指向のドメイン分析の結果抽出されます。

例えば、前編で説明したDomain Modelでは、Strategyパターンを利用しているものの、
BIDテーブルに対応したBidクラス、Itemテーブルに対応したItemクラス、
SALEテーブルに対応したSaleクラスとテーブルとクラスがほぼ一対一になっていますが、
ドメインオブジェクトの設計によっては同じテーブル構造のまま、Itemを抽象クラスとして用意して、
そのItemを継承したBookやComputerなどの具象クラスを作成する様な継承関係を実装するかもしれません。
その場合、それら継承関係をItemテーブルという１つのテーブルに格納しなければならないかも知れません。
つまり、Domain Modelが複雑になればなるほど、両者の違いは明確になってきます。
そもそもドメイン層とパーシステンス層という全く役割の異なった層のパターンですので違うのが当たり前ですが・・・
あと、Row Data Gatewayと似ているという点ですが、これは単純にActive Recordがドメインロジックを含むという点かと思われます。

Active Recordパターンのコードは、Row Data Gatewayとほぼ同じです。異なる点は、
それ自身にドメインロジックが含まれるという点ですので今回は省略します。

**デフォルトの名無しさん** · 2017/09/29(金) 23:44:51.15

パーシステンス層アーキテクチャパターンの選択
それでは、どのパーシステンス層のアーキテクチャパターンを選択すべきでしょうか？
これは、ドメイン層のアーキテクチャパターンの選択に大きく依存します。PoEAAでは、以下の様な組み合が考えられるとしています。

ドメイン層アーキテクチャパターンパーシステンス層アーキテクチャパターン
Transaction Scriptパターン Row Data Gatewayパターン
Table Data Gatewayパターン
Domain Modelパターン Active Recordパターン
Data Mapperパターン
Table Moduleパターン Table Data Gatewayパターン

ドメイン層とパーシステンス層はどの様な組み合わせでもかまいませんが、
より合わせやすいパターンは上記の様な組み合わせといっています。
また、少し視点を変えて各アーキテクチャパターンとシステムの論理的な階層の依存関係を表すと以下のように成るかと思われます。

【図】パーシステンス層/ドメイン層アーキテクチャパターンの依存関係

かなり抽象的かつ感覚的な図ですので、大体の感触をつかんでいただければ良いのですが、
１つ言えることは、システムの論理的な階層である、ドメイン層とパーシステンス層は、
其々異なる役割を持った層ですので、お互いに依存が少ないほうが好ましいと思われます。
その点で言うとDomain ModelとData Mapperがお互いの層で依存関係が少なく済みます。