UMLユースケースを定義した後のシステムのモデリング

Question

...次は？

どのアクターがどのアクションを実行するかを定義したら、どの方向に進みますか？データベースをモデル化しますか、それともクラスから始めますか？

より良いアプローチは、クラスのようなモデリング図から始めて、オブジェクト間の関係に焦点を合わせることだと思いました。 これは間違っていることが判明しました。クラスの詳細化に深く入り込み、システムが「動作しているように見えた」場合でも、データベースモデリングに行ったときに、前のフェーズで選択した位置にすべてが自然に収まらないからです。

クエリを実行し、基になるデータベースの抽象化を提供する大きなオブジェクトをメモリに構築するのではなく、アプリケーションロジックをデータベースに入れてデータを取得する速度を活用する必要があると言っている人々について読みました。 私はいつも、データベースが私のデータを保存し、それにアクセスするための高速な方法を提供するためにあると考えました。しかし、私は間違っているかもしれません、つまり、クラスのグループに置くのと同じロジック内にあるデータベースを本当に構築する必要がありますか？データベースにはこれを実現するツールが欠けていませんか？

適切な開始点の特定に失敗していると思います。データベースから開始することを選択した場合、単にデータを保存する場所として考えるだけでなく、アプリのロジックを実行してみましょうより高いレベルで＆quot;クラスから始めると、データベースがクラスの不自然な表現のように見えてしまいます。重要なものを見逃したり、適切なツールに適切な目的を割り当てないといった感覚を感じます。

これにどう対処しますか？ dbまたはクラスのモデリングを開始するかどうかを決定する際、経験上、どのようなアプローチが自然でクリーンな実装につながることが証明されていますか？

事前に感謝

Answer 1

堅牢性分析を使用して成功しました。

  

この記事は堅牢性に焦点を当てています   分析。分析には、   ユースケースの説明文と   の最初の推測セットを識別する   それぞれに参加するオブジェクト   ユースケース、次にこれらを分類する   オブジェクトを3つのタイプに分けます：

     

  
1. アクターがシステムとの通信に使用する境界オブジェクト。
  
2. 通常はドメインモデルのオブジェクトであるエンティティオブジェクト   （＆quot;運転設計の主題：   問題ドメイン、＆quot; 2001年1月）。
  
3. 制御オブジェクト（通常はコントローラーと呼びます。   多くの場合、実際のオブジェクトではありません）、   「接着剤」として機能します。境界間   オブジェクトとエンティティオブジェクト図1   これら3つの視覚的なアイコンを示しています   オブジェクトの種類。
  

エンティティオブジェクトは、（通常）データベースに格納されるものです/

クラスとデータベース間のマッピングでは、をお勧めしますS.Lottの記事「The ORM Problem」（彼はStackOverflowの参加者でもあります

Answer 2

テスト駆動開発を使用する場合は、最初にユニットテストを記述します。 あなたのクラスはあなたが行くにつれて概説されます。

データベース（モックまたはスタブオブジェクト）なしでビジネスロジックを開発するか、テストを進めながらデータベースを開発するかを選択できます。

データベースとドメインモデルは互いに1対1でマッピングしないでください。