database - 設計のトレース - 画面からデータベースへのトレーサビリティ

Question

これは漠然と次のように関連しています:

アプリケーションまたはモデル (データベース) を最初に設計する必要がありますか?

最初にデータベースから UI まで設計するか、それとも逆に設計するか?

しかし、私の質問はモデリングとアーティファクトに関するものであり、デザインの正しい方法に関するものではありません。機能 (ユース ケース)、画面、データベース要素 (特にテーブルと列) の間のリンクを最も明確に表現するのに最適な設計成果物を見つけようとしています。UML は非常にコード中心です。データベース モデルは非常にデータベース中心です。そして画面デザインはUI中心！

これが取引です...私のチームは製品の最初のリリースに取り組んでいます。ユースケースを使用し、次に画面設計を行い、データベース設計はこの 2 つから多少分離されました。バグの重大な領域は、ユースケースとそれに付随する画面およびデータベース間のトレーサビリティの欠如でした。私たちの製品では、ユースケースとデータベース要素の間に非常に高度な重複があります。多くのユース ケースは、データベース インフラストラクチャの 75% 以上に関係しています。そのため、データベースの設計領域で競合が多く、データベースの小さな変更が下位レベルのビジネス ロジックを混乱させるのは簡単です。

次のリリースでは、開発者と DBA に、各機能がデータベースのどの部分に影響を与えるかについて明確な洞察を得てもらいたいと思っています。ユースケース/画面設計のアプローチはうまく機能したので、そのままにしておきます...秘訣は、各ユースケースと画面をデータベースモデルにリンクすることです。これにより、関係が非常に明確になり、忘れにくくなります。

小規模なプロジェクト (私たちは 10 人しかいませんが、3 人以下のチームで作業することがよくあります) では、設計のこの部分を示すために独自のカスタム図を作成しました。実際のコードや SQL へのリンクなしで Visio で行われる、画面、UML、およびデータベース テーブルの一種の融合。最新の状態に保つには非常に手作業が必要であり、データベース モデリング ツールのようにコードを自動生成しないため、大規模なチームで機能するかどうかはわかりません。

推奨事項はありますか？これに対して一般的に受け入れられているメカニズムはありますか？

参考までに - 私たちはかなりのウォーターフォールであり、それはすぐに変わることはありません. そして、私たちはアーティファクトが大好きです... 「アジャイルへの切り替え」と言うのは、私たちのグループにとって実行可能な解決策ではありません。

Answer 1

あなたの質問からは、ユースケースがどれほど詳細かわかりません。それらは高レベルのユース ケースであり、詳細なユース ケースに分割されていない可能性があるという印象を受けます (おそらく、リレーションシップを含めたり拡張したりすることによって.

いずれにせよ、私は要件から始めて、それらをユースケースにたどることを好みます。ユース ケースとユース ケース図を書いている間、ドメイン モデル (高レベル クラス図) も作成しています。これは主に、利害関係者と話し合うためのものです (「それでよろしいですか?」)。

ユース ケースとドメイン モデルが完成したら、画面の設計に取り掛かることができます。また、画面間に複雑な相互作用がある場合は、アクティビティ モデルの作業を開始することもできます。UI を備えたクラスであるかのように画面を扱います。画面には FirstName 属性が含まれる場合があります。これは、ドメイン モデルの Person エンティティの FirstName 属性に関連していることに注意してください。ただし、FirstName 属性は、その画面でテキスト ボックスとして表示される場合があります。

同時に、物理データベースの設計が発生する可能性があります。これにより、クラスまたは ER ダイアグラムが作成され、ドメイン モデルまで遡ることができます。最終的に、画面属性またはアクティビティ モデリングの一部が、ドメイン モデルには存在しない物理データベース モデルの一部を参照していることに気付く場合があります。画面の「PersonalName」属性を People スキーマの Person テーブルの計算された PersonalName 列に関連付けても問題ありません。

この種の作業に使用するツールはSparx Enterprise Architectです。これは優れたツールであり、Professional エディションであっても、これらすべてを実行できます。

また、真実のために、私は主に自分でモデルを作成していると言わなければなりません。モデル、コード、およびデータベースが別々の人によって開発されているプロジェクトにまだ取り組んでいません。上記が「実生活」では機能しないと誰かが私に言った場合、私はそれらを信じざるを得ないかもしれません.

Answer 2

あなたの質問を明確に理解しているかどうかはわかりませんが、いくつかの合理的な仮定に基づいて回答しようとします...

基本的に、私の推奨事項は、 John Saundersがすでに提案したことと同じです: UML を優れた UML ツールと共に使用することを検討することです。ただし、特定の状況で重要になる可能性のあるいくつかのポイントを追加したいと思います。

何よりもまず、UML が「コード中心すぎる」とは思いません。それどころか、ほとんどすべての抽象化レベルで、ソフトウェア システムのほぼすべての側面をモデル化するために使用できます。(Sparx EA のような) 優れたツールを手元に置くことで、UML の優れた点は、(接続されていない一連の図面/チャートとは対照的に) 内部で明確に定義されたモデルを実際に取得できることです。その結果、ツール自体が探している機能 (DB からユース ケースへのトレーサビリティなど) を提供しない場合でも、少なくとも自動化 (または少なくとも半自動化) するオプションがあります。たとえば、UML モデルを XMI (標準!) にエクスポートし、そこから必要なトレーサビリティ関連情報を取得できます (たとえば、お気に入りのプログラミング/スクリプト言語用の XSL または XML 対応ライブラリを使用)。 .

ところで、Sparx EA について言えば...私はまだそのすべての機能を知っているわけではありませんが、非常に多くの機能を備えているため、クラス (またはクラスの属性さえも) を選択して表示することができても驚かないでしょう。何らかの方法でそれに依存する他のモデル要素。これをチェックしてみてください。

とはいえ、UML に関して少なくとも次の 2 つの重要な懸念があることは理解しています。

1. 必要なものを得るには、モデリングの詳細が多すぎるように見えるかもしれません。
2. あらゆる「万能ツール」と同様に、すでに使用している専用のモデリング ツールよりも著しく劣る可能性があります。

問題 #1 について: ここでも、優れた UML ツールが手元にあれば、好きなだけショートカットを作成できる可能性があります。たとえば、ユース ケースの非常に詳細で正確なアクティビティ モデルを構築する代わりに、ユース ケースに含まれるクラスだけに焦点を当てることができます (クラスをユース ケースまで追跡できるようにするのに十分です)。もちろん、同じことがUIにも当てはまります。

問題＃2に関して：ユースケース、UI、およびDBスキーマをモデル化するために現在どのツールを使用しているかはわかりません。したがって、理論的には、それらはすべて UML よりも優れているため、トレーサビリティーを容易にするためにそれらのいずれも放棄したくないという可能性があります。しかし、DB モデリング ツール (コード生成機能を備えたもの) だけが真に不可欠なツールである可能性があります。その場合でも、UML の使用を検討することをお勧めします。DB スキーマ レベルまでモデル化せず、ドメイン モデルのレベルで「停止」します (アプリケーションにそれがない場合でも!)。その時点で、UML ツールは、ドメイン モデル要素 (エンティティ、それらの属性、およびそれらの関係) からユース ケースおよび UI 要素までのトレーサビリティを提供します。また、ドメイン モデルと DB スキーマの間のマッピングは「空中」に放置される可能性があります。これは、ほとんどの場合、何も描画せずに追跡できるほど単純であるためです。これはあなたが望むものの 100% を与えないかもしれませんが、ほとんどの問題を軽減するのに十分な 80% を与えることができます.

結論: システムの 3 つの異なる側面をモデル化するために 3 つの異なるツール/テクノロジを使用している場合、これら 3 つの側面間の追跡可能性は、これら 3 つのツールに左右されることは明らかです。これらのツールを使えば可能です (これはおそらく、多くの骨の折れる手作業で立ち往生することになることを意味します)。今日現在、UML は、モデルを接続するのに役立ち、分析活動の大部分の自動化を可能にする、明確に定義され、広くサポートされている唯一の「リンガ フランカ」のようです。UML の「ただの描画ツール」 (ほとんどの Visio アドオンやステンシルなど) と真の UML モデリング ツール (Sparx EA やその他のツールなど) を区別するようにしてください。

Answer 3

ユースケースは出発点として適しています。

• ユース ケースを実行可能なテスト コードに変換します。このテスト コードでは、結果の戻り値がユース ケースの要件に従っていることを確認する必要があります。

• 特定してテストできる作業の部分が小さいほど、アプリケーションをより堅牢に構築できます。

• これは、ユースケースとデータベースの大部分および GUI との相互作用が理解しやすくなることを意味します。

さまざまなレイヤーの完全な事前設計が行われている複雑なプロジェクトでは、アーキテクチャやビジネス ロジックの相互作用をロックダウンすることは困難です。要件を実装するポイントに到達して初めて、要件を容易にすることができるものについて真に学ぶことができます。

開発者として、可能な限り最善の方法で仕事を遂行するのに役立つテクニック、ツール、およびプロセスを見つけてください。これらをその起源で判断しないでください。あなたを可能な限り最高の開発者にする上で、それらの価値を判断してください。

アジャイルの世界のいくつかのアイテムは、確かに私の仕事の質と生産性に大きな違いをもたらしました. これには、アップルカートを捨てて、経験豊富なウォーターフォールチームを混乱させる必要はありません.

Answer 4

データベースは問題ドメインをモデル化する必要があります。そこから解決策 (真実) を抽出できるように、完全にモデル化する必要があります。悪い設計とは、基本的にデータベースに対して「嘘をつく」ことであり (無効なデータや関係の可能性を許す)、データベースに対して「嘘をつく」と、質問したときにデータベースが「嘘をつく」ことになります。

簡単な例としては、リレーションが 1 対多にしかならない多対多リレーションのモデル化、値を null にすることはできないと仮定すること、または外部キーを属性として扱うことです。これらの多くは、適切な正規化によって回避できます。これには、何がキーで何がキーでないかを明示的に調べる必要があります。

モデルで「不正な状態を表現できないようにする」ことにより、不可能なことをチェックしたり、関係が可能であることを検証したりするための「防御的な」コードを書く必要がなくなります。

これにより、コードを記述するコストが削減されます。不可能なことを防ぐのではなく、ほとんどの場合、コードを実行する必要があることに集中できるからです。