私が苦労していることの1つは、コードを書く前にアプリケーションのアーキテクチャを計画することです。
アプリケーションが何をする必要があるかを絞り込むための要件を収集することを意味するのではなく、クラス全体、データ、およびフロー構造をレイアウトするための良い方法を効果的に考え、それらの考えを繰り返して、信頼できる計画を立てることを意味します。 IDEを開く前にアクションを念頭に置いてください。現時点では、IDEを開いて空白のプロジェクトを作成し、ビットとボブの作成を開始して、そこからデザインを「成長」させるのは簡単です。
私はUMLを収集することはこれを行う1つの方法ですが、私はそれを経験したことがないので、ちょっと曖昧に思えます。
コードを書く前に、アプリケーションのアーキテクチャをどのように計画しますか？UMLが進むべき道である場合、小さなアプリケーションの開発者に簡潔で実用的な紹介をお勧めできますか？
ご意見ありがとうございます。
回答:
私は次のことを考慮します。
次に、システムをブラックボックスと見なし始めます。
次に、これにより、さまざまな内部ブラックボックスで構成されるシステムのビューが表示され始めます。各ブラックボックスは、同じ方法でさらに分解できます。
UMLは、そのような動作を表すのに非常に適しています。ほとんどのシステムは、UMLの多くのコンポーネントのうちの2つを使用するだけで説明できます。
説明する必要のある動作に並列性がある場合は、アクティビティ図も必要になる場合があります。
UMLを学ぶための優れたリソースは、Martin Fowlerの優れた本「UMLDistilled」（Amazonリンク-スクリプトキディリンクナチスのためにサニタイズされています（-:)）です。この本では、の各コンポーネントの重要な部分を簡単に説明しています。 UML。
ああ。私が説明したのは、ほとんどIvarJacobsonのアプローチです。ジェイコブソンはOOの3つのアミーゴの1つです。実際、UMLは当初、3つのアミーゴを形成する他の2人、GradyBoochとJimRumbaughによって開発されました。
あなたは間違いなくスティーブマコネルのコードコンプリートを見てください-そして特に「建設中のデザイン」に関する彼のプレゼントの章を見てください
あなたは彼のウェブサイトからそれをダウンロードすることができます：
.NET向けに開発している場合、Microsoftはアプリケーションアーキテクチャガイド2.0b1を（無料の電子書籍として！）公開したばかりです。コードを書く前に、アーキテクチャの計画に関する非常に優れた情報をたくさん提供します。
もしあなたが必死なら、非.NETベースのアーキテクチャにそれの大きな塊を使うことができると思います。
私は主に、アーキテクチャの多くが事前に決定されているWeb開発（WebForms、現在はMVC）を行っており、私のプロジェクトのほとんどは、1年もかからない、かなり小規模な1人の作業であると述べます。また、ビジネスオブジェクトとデータの相互作用をそれぞれ処理するためのORMとDALを用意することも知っています。最近、これにLINQを使用するように切り替えました。そのため、「設計」の多くは、データベースの設計とDBMLデザイナを介したマッピングになります。
通常、私はTDD（テスト駆動開発）の方法で作業します。建築やデザインの詳細に前もって取り組むことはあまりありません。ストーリーを介して、ユーザーとアプリケーションの全体的なやり取りを収集します。ストーリーを使用してインタラクションデザインを作成し、アプリケーションの主要コンポーネントを発見します。このプロセスでは、お客様と一緒に多くのホワイトボードを作成します。ダイアグラム形式を維持するのに十分重要であると思われる場合は、デジタルカメラで詳細をキャプチャすることがあります。主に私のストーリーはウィキにストーリー形式でキャプチャされます。最終的に、ストーリーはリリースとイテレーションに編成されます。
この時までに、私は通常、アーキテクチャについてかなり良い考えを持っています。それが複雑であるか、通常の慣行とは異なる異常な部分がある場合、または他の誰かと作業している場合（一般的ではありません）、（再びホワイトボードに）図を作成します。複雑なインタラクションについても同じことが言えます。ホワイトボード上でページレイアウトとフローを設計し、そのセクションが完了するまでそれを維持（またはカメラ経由でキャプチャ）する場合があります。どこに行くのか、最初に何をする必要があるのかについての一般的な考えが決まったら、最初のストーリーのテストを書き始めます。通常、これは次のようになります。「これを行うには、これらのクラスが必要です。これから始めて、これを行う必要があります。」それから私は陽気にTDDを始め、アーキテクチャ/デザインはアプリケーションのニーズから成長します。
定期的に、コードを何度か書き直したり、「これは本当ににおいがする」と思ったりすることがあります。デザインをリファクタリングして、重複を削除するか、においのある部分をよりエレガントなものに置き換えます。主に、優れた設計原則に従いながら機能を低下させることに関心があります。既知のパターンを使用し、適切な原則に注意を払うことで、かなりうまくいくことがわかりました。
http://dn.codegear.com/article/31863
私はUMLを使用していますが、そのガイドは非常に便利で読みやすいと思います。何か違うものが必要な場合はお知らせください。
UMLは表記法です。それはあなたのデザインを記録する方法ですが、（私の意見では）デザインを行う方法ではありません。書き留める必要がある場合は、UMLをお勧めします。ただし、UMLが「最高」であるからではなく、他の人がすでに読み方を知っている標準であり、独自の「標準」を発明するよりも優れているからです。
私は、UMLへの最良の導入はまだだと思うUML蒸留それの簡潔には、それを使用する場所の実用的なガイダンスを提供し、そしてそれはあなたがそれをするために全体のUML / RUPのストーリーに購入する必要はありませんオフになるため、Martin Fowler氏によって、便利である
設計を行うのは難しいです.1つのStackOverflowの回答に実際に取り込むことはできません。残念ながら、私のデザインスキルは何年にもわたって進化してきたため、参照できるソースは1つもありません。
しかし、私が有用だと思ったモデルの1つは、堅牢性分析です（グーグルで検索しますが、ここにイントロがあります）。システムが何をすべきかについてのユースケース、関係するもののドメインモデルがある場合、堅牢性分析は、2つを接続し、システムの主要コンポーネントが何である必要があるかを理解するのに役立つツールであることがわかりました。 。
しかし、最善のアドバイスは広く読まれ、よく考え、実践します。それは純粋に教えることができるスキルではありません、あなたは実際にそれをしなければなりません。
私は少し以上前もって計画を立てるほど頭が良くありません。事前に計画を立てると、いつも間違った計画になりますが、今では悪い計画にn日を費やしています。ホワイトボードでの制限は約15分と思われます。
基本的に、私は自分が正しい方向に向かっているかどうかを確認するためにできる限りの作業をしていません。
私は重要な質問のために私の設計を調べます：AがBからCを行うとき、それはDにとって十分に速いでしょうか？そうでない場合は、別のデザインが必要です。これらの質問のそれぞれは、スパイクで答えることができます。スパイクが良さそうな場合は、デザインがあり、それを拡張するときが来ました。
私はできるだけ早く実際の顧客価値を得る方向にコーディングしているので、顧客は私がどこに行くべきかを教えてくれます。
私はいつも物事を間違えるので、私はそれらを正しくするのを助けるためにリファクタリングに頼っています。リファクタリングはリスクが高いので、ユニットテストを作成する必要があります。結合のために事後にユニットテストを書くのは難しいので、私は最初にテストを書きます。このことについて規律を保つのは難しく、脳が異なれば物事の見方も異なるので、私は仲間にコーディングしてもらいたいと思っています。私のコーディング仲間は鼻を持っているので、私は定期的にシャワーを浴びます。
それを「エクストリームプログラミング」と呼びましょう。
「ホワイトボード、スケッチ、付箋は優れたデザインツールです。複雑なモデリングツールは、照明よりも気が散る傾向があります。」VenkatSubramaniamとAndyHuntによるアジャイル開発者の実践から。
私は何もできるとは確信していません実装前に事前に計画してください。私は10年の経験がありますが、それは4社（1社の2サイトを含み、ほぼ正反対でした）でしかなく、私の経験のほとんどは巨大なクラスターの監視に関するものでした****** **が発生します。リファクタリングのようなものが本当に最善の方法だと思い始めていますが、同時に私の経験は限られていることに気づき、私は自分が見たものに反応しているだけかもしれません。私が本当に知りたいのは、最高の経験を積んで適切な結論に到達できるようにする方法ですが、近道はないようで、人々が間違ったことをしているのを見るのに多くの時間がかかります:(。I （製品の展開が成功したことからもわかるように）人々が正しいことをする会社で働きたいと思っています。
違います：UMLはアプリケーションアーキテクチャに使用できますが、技術アーキテクチャ（フレームワーク、クラス図、シーケンス図など）に使用されることがよくあります。これは、これらの図を開発と同期させるのが最も簡単な場所だからです。 。
アプリケーションアーキテクチャは、いくつかの機能仕様（将来の実装について何も想定せずに操作の性質とフローを説明する）を取得し、それらを技術仕様に変換するときに発生します。
これらの仕様は、いくつかのビジネスおよび機能のニーズを実装するために必要なアプリケーションを表しています。
したがって、複数の大規模な財務ポートフォリオ（機能仕様）を処理する必要がある場合は、その大規模な仕様を次のように分割する必要があると判断する可能性があります。
したがって、基本的に、アプリケーションアーキテクチャについて考えることは、一貫した方法で開発する必要のある「ファイルのグループ」を決定することです（同じファイルのグループでランチャー、GUI、ディスパッチャーなどを開発することはできません...：それら同じペースで進化することはできません）
アプリケーションアーキテクチャが明確に定義されている場合、通常、その各コンポーネントは構成コンポーネントの候補として適しています。つまり、すべてをVCS（バージョン管理システム）にバージョン管理できるファイルのグループです。つまり、すべてのファイルは次のようになります。そのアプリケーションのスナップショットを記録する必要があるたびに一緒にラベルが付けられます（ここでも、すべてのシステムにラベルを付けるのは難しく、各アプリケーションを同時に安定した状態にすることはできません）
私はしばらくの間建築をやっています。私はBPMLを使用して最初にビジネスプロセスを改良し、次にUMLを使用してさまざまな詳細をキャプチャします。3番目のステップは一般的にERDです！BPMLとUMLを使い終える頃には、ERDはかなり安定しています。完璧な計画はなく、100％抽象化されることもありません。リファクタリングを計画します。目標は、リファクタリングを可能な限り最小限に抑えることです。
私は自分の考えを2つの領域に分解しようとしています。それは、私が操作しようとしていることの表現と、それらを使って何をしようとしているのかです。
操作しようとしているものをモデル化しようとすると、一連の個別のアイテム定義が思い浮かびます。eコマースサイトには、SKU、製品、顧客などが含まれます。また、注文やカテゴリなど、重要ではないものもいくつかあります。システムにすべての「名詞」が入ったら、これらのオブジェクトが互いにどのように関連しているかを示すドメインモデルを作成します。注文には顧客と複数のSKUがあり、多くのSKUが製品にグループ化されています。オン。
これらのドメインモデルは、UMLドメインモデル、クラス図、およびSQLERDとして表すことができます。
システムの名詞を理解したら、動詞に移ります。たとえば、これらの各項目が注文をコミットするために実行する操作です。これらは通常、私の機能要件のユースケースに非常によく対応しています。私が見つけたこれらを表現する最も簡単な方法は、UMLシーケンス、アクティビティ、コラボレーション図、またはスイムレーン図です。
これを反復プロセスと考えることが重要です。ドメインのちょっとしたコーナーを実行してから、アクションに取り組み、次に戻ります。理想的には、コードを書いて試してみる時間があります。デザインがアプリケーションよりもはるかに進んでいることは絶対に避けてください。すべての完全で最終的なアーキテクチャを構築していると考える場合、このプロセスは通常ひどいものです。実際、あなたがやろうとしているのは、チームが開発を進めるときに共有する基本的な基盤を確立することだけです。あなたは主に、チームメンバーがシステムを説明するときに使用する共有語彙を作成しているのであって、それがどのように行われなければならないかについての法律を定めているのではありません。
コーディングする前にシステムを完全に考えるのに苦労しています。一部のコンポーネントをざっと見ただけで、思ったよりもはるかに複雑であることに後で気付くのは簡単すぎます。
1つの解決策は、本当に一生懸命努力することです。どこにでもUMLを書いてください。すべてのクラスを通過します。それが他のクラスとどのように相互作用するかを考えてください。これを行うのは難しいです。
私が好きなのは、最初に一般的な概要を説明することです。私はUMLが好きではありませんが、要点を理解する図を描くのは好きです。それから私はそれを実装し始めます。空のメソッドでクラス構造を書き出しているだけでも、以前に見逃したことがよくあるので、デザインを更新します。コーディングをしていると、何か別のことをする必要があることに気付くので、デザインを更新します。これは反復的なプロセスです。「最初にすべてを設計し、次にすべてを実装する」という概念はウォーターフォールモデルとして知られており、他の人はそれがソフトウェアの悪いやり方であることを示していると思います。