Drop version 2.0 Beta 追加・修正履歴

このページは、Drop ver2.0 Betaのドキュメント修正と追加した箇所を履歴として記録しているページです。

3月11日

  • 第９章Drop開発サイクルの考え方の説明文章を変更。
  • 開発フェーズの第２３章から２８章まで。表現の誤りを無くし、説明不足部分を追加。
  • はじめにDropの読み方・使い方の誤字を変更。
  • 第４章Dropの目指すものの図4-2からDropのバージョンを外す。
  • 第５章プロジェクト構成の問題の文章を少しだけ変更。
  • 第１０章開発サイクルの基本形の文章を少しだけ変更。
  • 第１１章開発サイクルの応用の文章を少しだけ変更。
  • 第１２章プロトタイプ開発の利用の文章を少しだけ変更。

2月15日

  • はじめにDropの読み方・使い方を追加。
  • コンセプト編とプロジェクトチーム構成編について、うまく説明できていなかった部分を修正。
  • Q&Aに２件追加。

10月23日

  • 第２５章システムテスト・評価にシステム評価を追加
  • 第２８章パッケージテスト・評価にパッケージ評価を追加
  • 第３１章ドキュメント名の変更
    • 「システム共通仕様書」を「システムアーキテクチャ仕様書」とする。
    • 「アプリケーションクラス仕様書」を「アプリケーション設計書」とする。
  • 第１章パッケージの解説を修正。
  • 第２２章問題領域分析フェーズの要求仕様書の作成を詳しくする。
  • 第３０章テスト項目表の作成フェーズをテスト・評価から設計・実装フェーズに修正（誤り修正）
  • 第３０章～第３４章誤字・脱字・言い回し修正。

10月9日

  • 第９章Drop開発サイクルの考え方に、「ソフトウェア開発形態とDrop開発サイクル 」を追加する。
  • 第１０章開発サイクル基本形にて、契約主導開発サイクルを解説し、「複雑システム型（積み上げ反復の応用）」を追加する。
  • 第１１章開発サイクルの応用にて、発想主導主導開発サイクルを追加する。
  • 第２７章　コンポーネント実装・設計の図27-1　インタフェースと実装を別クラスにするの解説に実装方法を記述する。
  • 開発ドキュメント編の内容を充実させる。
  • 第２章Drop構成用語集の図2-2開発プロセス中の「アプリケーション開発」を「システム開発」に変更。（ネーミングの一貫性のために！）
  • 第２２章　問題領域分析の「２２．５ 　コンセプト主導のソフトウェア開発における要求」の名前を発想主導型に変える。（ネーミングの一貫性のために！）
  • 第１７章シーケンス図17-10の解説の中で、transmission timeの記述に誤りあり、「find()からFindFinish()まで」に変更。Thanks >古橋健一さん
  • 第２４章から第２９章まで、ヘンテコな文章表現を修正。:-)

9月30日

  • 第２３章「システム共通設計」をオブジェクト設計に関する解説を付加する。
  • 開発フェーズ編の残りの章（２４章から２９章まで）を追加
  • 開発ドキュメント編を追加
  • 第１６章　静的構造モデルのインタフェースの注釈が実装言語と直接結びついているような誤解を招くことがfj.comp.oopsの議論の中で指摘され、それにより「インタフェースの表記は直接的にプログラム言語機能と結びついているものではない。」ということを強調した文章に修正した。

9月7日

8月31日

  • 第１章コンポーネントの解説の中で「アプリケーション内再利用」の目的として、「情報を隠蔽することで、システム全体の見通しが良くなることに期待する」ことを目的とされる点を追記。

8月18日

  • 第１８章　再利用基盤モデルの実施プロセスの解説の中で使用していた「概念オブジェクト」を「要求オブジェクト」に修正。また、「アイデア先行型プロセス」を「コンセプト主導型プロセス」に修正し、問題領域分析フェーズとの用語の一貫性を図る。
  • 第２２章　「問題領域分析フェーズ」追加
  • 第２１章　「開発フェーズの考え方」追加
  • 第１５章　「シネマスコープモデル」追加
  • Q&Aに８件追加する。（合計１８件）
  • Drop仕様を定める上での議論の過程を公開する。
  • 要求モデルの対象とするオブジェクトの名前を「概念オブジェクト」から「要求オブジェクト」に変更する。第３章と第１８章の変更。
  • 第１章　再利用基盤モデルの縦レイアと横レイアを役割レイアと再利用レイアに変更。

7月14日

7月9日

  • 修正履歴を作成

7月8日

  • 第 ２章　　文章にモデルの解説を追加する
  • 第１３章　クラス図のインタフェースを記述するための拡張継承の解説を追加する
  • 第１３章　にUMLのステレオタイプの解説を追加する
  • 第１６章　クラス図限定子の分かりづらい説明例を取り去る（図と説明の変更）
  • 第１７章　コラボレーション図のリンク実現方式について解説を追加する
  • 第１４章　オブジェクトモデルのライフサイクル追加

7月7日

6月28日

  • 第１９章　図番、章立てが１８章となっていたため１９章に変更

6月27日

6月26日

6月25日

  • デイレクトリ名とファイル名の変更(chapterをpartへ、section.htmlをchapter.htmlへ)
  • 第１３章の文章の変更と図の関連多重度を厳密に書いた。またシステム構造図まで図に網羅させた。
  • 第１７章のコラボレーション図とシーケンス図にアクテイブ追加、DBをコンポーネント表記に修正。

気になる作業とその進み具合

問題箇所 改善内容 解決日
第１章 アプリケーション開発とエキストラの解説をもっと親切に書きなおす。 6/27
第２章 モデルの考え方の解説追加 7/8
第４章 「Dropの目指すもの」を現時点の視野を広げた新たな視点にて書き直し。第５章の問題を一部ここに移動する。
第５章 開発プロセスに関係する問題に的を絞る。
第８章 Dropによる組織改革「大岩を動かすには」の部分。
第１１章 拡張・改良プロセスの書きかけ部分。「開発モデル編」を書き終わってから補充予定。
第１３章 ステレオタイプの解説追加。 7/8
第１６章 クラス図にアクテイブクラスの表記を追加予定。 7/7
第１６章 インタフェースの解説を補足。 7/7
第１８章 クラスレイアカテゴリ図の使い方を書く。
Q&Aがたりない。
カテゴリセットとフレームワーク、コンポーネント、パッケージの関係を説明する。
第１９章 システム構造図の応用例を載せる。
第１５章 簡単な利用例を載せる。

懸案事項

NO 問題箇所 内容 発生日 解決日 反映箇所
１ 第５章 製品開発サイクルについて 1998/8/11 1998/10/09 1 ９章、１０章、１１章
２ 第１５章・第２０章 シネマスコープモデルとDROの関係 1998/9/7 1998/9/7 １５章と２０章
３ 第１８章 DropにおけるUMLインタフェース表記の解釈について 1998/9/11 1998/9/30 インタフェース表記の注釈

２．シネマスコープモデルとDROの関係

新たに導入したシネマスコープモデルは、要求のモデル化を目的としたものであり、簡易ではあるが表記法をともなうためモデル編に入れた。しかし、Dropには元々DROという要求のモデル化があり、それは表記法を提供していないため手法としていた。両者を一つの方法論に統合させようとすると下記の矛盾に悩まされてしまい、執筆が一歩も先へ進まなくなった。

問題１．モデルと手法
そもそもDROが手法であるなら、シネマスコープもモデルというより手法といった方がよいのでは？
もともと手法とモデルは切り離せないので、両者を方法論で使い分けすること自体ナンセンス？
問題２．制御中心とデータ中心
シネマスコープでは、オブジェクトの候補を見つける際に、どちらかというとオブジェクトの制御に着目するのに対し、DROはデータに着目する。この２つは要求モデル完成にむけて同時並行的に進むべきではないか？
しかし、そうなるとDROはどうやってオブジェクトを見つけるのか？結局、シネマスコープモデルと同様な手順が必要となってしまう。
問題３・開発フェーズとの対応
問題３で、DROをProcessをモデル化できるように拡張した場合に要求のモデル化を具体的なソフトウェア環境を想定したアークテクチャ設計と混同してしまうのではないか？

上記の問題に対して、まだ満足のいく結論は出しきれていない。もしかすると今後、シネマスコープモデルとDROを統合するかもしれない。しかし、Version 2.0では上記問題に対して下記の結論をだした。

問題１．モデルと手法

モデルと手法には、以下の性質的な違いがある。この違いから、方法論の中でモデル編と手法編にわけることは問題ないと判断する。Dropの手法編は、複数のモデルを使うための方法と定義する。

  • 手法には複数のモデルを組み合わせるようなプロセスが含まれている。
  • モデルは手法よりも普遍的な面が多く、なんらかの図式表現を伴う。
  • モデルにもなんらかの手法が組み込まれているが、それは単独のモデルに閉じた手法である。

問題２．制御中心とデータ中心

以下の理由によりDROをProcess分析を含む手法に拡張する。この拡張部分は、シネマスコープモデルの構想の中から、手法部分を取り出し、DROに部分移動したものとなっている。

  • 旧DropのDROは、データ中心の要求分析アプローチであった。これは、制御中心のソフトウェアには有効的ではなかった。
  • シネマスコープモデルは、オブジェクトの候補(イメージ)を抽出するのが役割であり、Prcoessをデザインするフェーズがなかった。
  • そもそもオブジェクト分析時には、オブジェクトの候補からPrcoessを見つけ、そこからDataManageを取り出すよいうような手順を踏むことがが多いと考えた。

問題３・開発フェーズとの対応

シネマスコープモデルとDROを使ったモデリングは、「要求のモデル化」と位置づける。Dropでは、下記のフェーズで使われることにする。

  • 問題領域分析フェーズ..........開発システムの要求をモデル化する
  • コンポーネント分析フェーズ..........コンポーネントの要求をモデル化する

また、要求モデルの対象を下記の範囲と定めた。（その効果など、詳しい内容はこちらを！）

DROを利用する目的は、要求のモデル化にある。要求をモデル化するということは、抽象化された理想的なソフトウェア環境上に、要求を実現するためのクラスの構造を具体化することである。ここでの理想的なソフトウェア環境とは、ソフトウェアが実際に実装されるフレームワークやコンポーネントといった具体的なソフトウェア環境を想定しないものを意味する。

Dropへ戻る

Copyright (C) 1998 NJK CORPORATION. All Right Reserved.

この記事のトップへ