オブジェクト指向分析/設計では、データベースをどのように設計するのだろうか

オブジェクト指向分析/設計では、データベースをどのように設計するのだろうか。

■オブジェクト指向分析/設計(OOAD)のアーキテクチャ

まず、オブジェクト指向分析/設計(OOAD)のアーキテクチャを見てみましょう。



UMLモデリングの本質 第2版 良いモデルを作るための知識と実践』より

オブジェクト指向分析/設計では、永続層にオブジェクト指向データベース(OODB)が使われるようになることを期待していたように思います。
オブジェクト指向データベース(OODB)を使えば、インスタンス化したオブジェクトを加工せずにそのまま格納できます。
そのため、データベースの設計は必要ありませんでした。

しかし、2012年現在、オブジェクト指向データベース(OODB)はそれほど使われていないように思います。
現実には、リレーショナルデータベース(RDB)が主流となっています。

■リレーショナルデータベース(RDB)を永続層に使用する場合の設計方法

リレーショナルデータベース(RDB)を永続層に使用する場合、2つの考え方があります。

■■(1)DOA併用

1つは、リレーショナルデータベース(RDB)を生かして、データベースを設計する方法です。
永続層はデータ中心アプローチ(DOA)で設計し、それより上の層はオブジェクト指向分析/設計(OOAD)で設計します。


UMLによる一気通貫DBシステム設計』より

この手法については、名著『UMLによる一気通貫DBシステム設計』が入門書としておすすめです。

オブジェクト指向分析/設計の対象領域とデータモデリングの対象領域はそれぞれ異なっており、本来は役割分担すべきものなのです。

UMLによる一気通貫DBシステム設計』より

■■(2)あくまでOODB

もう一つは、リレーショナルデータベース(RDB)をオブジェクトの保存場所として使用します。
オブジェクトの構造とテーブルの構造は一致します。

■■ActiveRecordの場合

Ruby on RailsのO/R マッピングライブラリであるActiveRecordを例に考えてみます。

ActiveRecordライブラリでは、1つのテーブルは1つのクラスに対応します。
これはテーブルはオブジェクトを永続化するための場所として考えているためだと思います。
idはプライマリキーというよりも、オブジェクト識別子(OID)のように見えます。

Railsのマインドセットには「テーブルをオブジェクトと同一構造にし、プライマリーキーにはinteger型のサロゲートキーを設定しておけば、かなり楽になる」というものがある。

Martin Fowler’s Bliki in Japanese – エンタープライズRails

ActiveRecordにはComposite Primary Keysという複合主キーの機能を追加するライブラリがあります。
このようなライブラリが必要とされるのは、データベースをDOAで設計しているためではないかと思います。

■考察

  • シンプルなシステムであれば「(2)あくまでOODB」
    業務システムなら「(1)DOA併用」だろうか?

  • 結局はケースバイケースか?

継続的インテグレーション入門 開発プロセスを自動化する47の作法

継続的インテグレーション入門 開発プロセスを自動化する47の作法』は、継続的インテグレーションの実践的な入門書です。
複数人のチームでアジャイル開発をするなら、おさえておきたいノウハウです。
継続的インテグレーションによって、繰り返しが多い作業や間違いやすい作業を自動化することで、開発がスムーズに進むようになるでしょう。

この本で学べることは、バージョン管理リポジトリのソースコードが常に正しい状態であることを自動的に検証するための仕組みです。
継続的インテグレーションを実践することで、次のような情報を得ることができるようになります。

  • すべてのソフトウェアコンポーネントが協調して動いているか?
  • コードの複雑度はどれくらいか?
  • チーム内では定められたコーディング標準が遵守されているか?
  • 自動化されたテストによってどれくらいのコードが網羅されているか?
  • 最新の変更後にすべてのテストが成功したか?
  • 自分のアプリケーションは今まで通り性能要件を満たしているか?
  • 最後のデプロイ時に何か問題はなかったか?

本書が扱っているプログラム言語はJavaとMicrosoft .Netです。
これは規模の大きい開発には、これらの言語がよく使われているからだと思います。
もちろん本書の知識はどのような言語を使っていても活用できます。

ようやく継続的インテグレーションについて書籍を日本語で読めるようになりました。
Web上にも継続的インテグレーションについての情報は点在していますが、効率よく学ぼうと思ったら、本書を読むことをお勧めします。

関連リンク

アジャイル開発に適した契約とは

リーンソフトウエア開発~アジャイル開発を実践する22の方法~』を読んで、アジャイル開発に適した契約について考えた。

一般的である定額契約(一括請負契約)は、アジャイル開発に不適なのは言うまでもない。
定額契約(一括請負契約)では開発が始まる前にコストを見積もる。
しかし、完全な計画を立てることができないからこそ、アジャイル開発が必要になったのだ。

リーンソフトウエア開発』では、時間資源契約(時間費用契約)・多段階契約・目標コスト契約・利益共有契約について、考察している。
なお、トヨタの金型契約は目標コスト契約とのこと。
目標コスト契約は、『クリティカルチェーン』でも同じような方法が紹介されていたような記憶があるが、手元にないので確認できない。

顧客にとって、定額契約(一括請負契約)がもっとも有利な契約である。
アジャイル開発をするためには、アジャイル開発を顧客に理解してもらい、目標コスト契約や利益共有契約のほうに契約方式を変えていかなければならない。

日本のソフトウェア産業がいつまでもダメな理由

日本のソフトウェア産業がいつまでもダメな理由

人月でビジネスをしているITベンダー(SIer)はダメだ。
という話。

解決策としては、
ダメな会社は辞めよう。
ということか。

座談会をまとめて一冊の本にしたらしい。
座談会の参加者はおそらく全員40歳以上だろう。
話の内容に偏りと違和感を感じた。

Amazonの高評価が不思議だ。