4

私は情報検索に興味のあるソフトウェア開発者です。現在、私は 3 番目の検索エンジン プロジェクトに取り組んでおり、同じバグなどで何度も何度も書かれているボイラープレート コードの量に非常に不満を感じています。

基本的な検索エンジンは、次の 2 つの「レイヤー」で構成される形式言語で記述できる非常に単純な獣です。

  1. 「プリミティブのレイヤー」（または公理、カーネル言語-名前の付け方がわからない）。それらは、いくつかのセット (リソースのセットとして - ファイル、Web サイト)、セット上の関係 (「サイト A がサイト B にリンクする」など)、および「リソース A へのストリームを開く」、「ストリームからレコードを読み取る」などの単純な操作で構成されます。 「N 個のストリームをマージ」、「フィールド F によるレコードのインデックス セット」など。また、「YAML 形式でストリームを保存」、「XML 形式からストリームをロード」など、多くのデータ変換があります。

  2. 「アプリケーション層」 - 「新しいリソースの収集」、「収集されたリソースのクロール」、「クロールされたリソースのデータベースへのマージ」、「クロールされたリソースのインデックス作成」、「インデックスのマージ」など、検索エンジンのライフサイクルを形成するいくつかの非常に高レベルの操作など。この高レベルの操作はすべて、1 から「プリミティブ」の用語で表現できます。

このような高レベルの表現は、選択したプログラミング言語で簡単にテストでき、おそらく正式に証明され、実装 (またはコード生成) できます。

では、質問: この方法でシステムを設計する人はいますか? 形式的に、厳密に (おそらく代数/群論のレベルでも)、厳密なトップダウン アプローチで? 何を読めば学べますか?

4

6 に答える 6

4

重要なシステム (原子力発電所、航空機、列車制御システムなど) は、探しているものと同様のトップダウン アプローチで開発されます。しかし、上位レベルはまったくプログラム化されていません。それはカーネル層やアプリケーション層ではなく、コンポーネント、サブコンポーネントに洗練された高レベルの設計であり、各レベルで正確な仕様を備えています。

仕様は、正式なもの (指定されたコンポーネントが利用可能になった時点で自動的に検証されることを意図したもの) であっても、そうでないもの (テスト、コード レビュー、または適切な方法で検証されることを意図したもの) であってもかまいません。率直に言って、2009 年には、ほとんどの場合フォーマルではありませんが、トレンドは明らかにその方向に進んでいます.

質問のタグで正式なアプローチについて言及しているので、そのトピックに興味があるに違いありませんが、現時点ではニッチです。特に、これらの方法を検索エンジン プロジェクトに経済的に適用する方法がわかりません。とにかく、これらのメソッドが機能する分野でどのように適用されるかについて詳しく知りたい場合は、いくつかのリンクを次に示します。

誰かが Z に言及しました: Z は仕様言語であり、実行可能になるまで仕様を改良し改良するフレームワークはBと呼ばれます。合金にも興味があるかもしれません。最後に、既存のプログラミング言語の正式な仕様言語があります。この傾向はJava 用のJMLから始まり、他の多くの人に影響を与えました。私は、C の仕様言語であるACSLを定義した人々のグループで働いています。

于 2009-11-25T19:52:02.893 に答える
1

ほとんどのプロジェクトでは、標準の 3 層アーキテクチャに基づくアーキテクチャを採用しています。

  • UI : 手動でテスト済み
  • ビジネス : モッキングでテスト済み
  • プロキシ/データ アクセス: 統合テストでテスト済み

アーキテクチャ パターンの詳細については、http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science)を参照してください。

于 2009-11-25T14:45:59.500 に答える
1

簡単に言えば、「はい、程度の差はありますが」です。

さまざまな組織がさまざまな程度の厳密さでソフトウェア開発に取り組んでいますが、各レイヤーが次のレイヤーによって提供されるサービスへの非常に制約された、正確に設計されたインターフェイスの観点からその責任を処理する、レイヤード デザインの概念はうまくいきます。設立。テスト駆動開発、依存性注入、インターフェイスの設計がますます受け入れられていることは、これらのアイデアがソフトウェア開発の標準としてゆっくりと確立されつつあることの証拠として挙げたいと思います。

しかし、ソフトウェア開発は、さまざまな規模で、さまざまな目的で行われています。規模と複雑さが増すにつれて、物理的な製造において精密工学のレベルが上がるのとちょうど同じように (たとえば、ジェット エンジン メーカーと額縁製作者の比較)、一部のソフトウェア開発者は、精度の欠如を許容できるほど性能と使用規模が小さいシステムを扱います。または長期にわたる欠陥 (例: 典型的な Web 開発者とアビオニクスまたは組み込み医療機器に取り組んでいる開発者)。

私の見解では、精度と厳密なレイヤー化は、欠陥の結果が十分に高い場合にのみ発生するコストと見なされることがよくあります. しかし、少なくともインターネット規模で機能するミッション クリティカルなシステムの開発においては、それがゆっくりと良い方向に変化していることがわかります。

于 2009-11-25T13:38:49.867 に答える
0

IEEE-1471を見ることをお勧めします。

于 2009-12-03T20:16:02.963 に答える
0

再利用可能なコードはそのような方法で作成する必要があるというあなたの仮定に異議を唱えます。

コードの再利用を目標に設計されたシステムを使用している職場を見てきましたが、最終的に再利用はほとんどなく、全体的に複雑になっています。

SOLID の原則に固執し、TDD を実行し、DRY、YAGNI、および KISS を念頭に置くことは、合理的なレベルの再利用を達成するのに大いに役立ちます。

あなたが言及した操作は、すべてが同じクラスで終わるべきではないさまざまな責任の完璧な例です。

ストリームをリソース A に開く」、「ストリームからレコードを読み取る」、「N 個のストリームをマージする」、「フィールド F によるレコードのインデックス セット」など。また、「ストリームを YAML 形式で保存する」など、多くのデータ変換があります。 、「XML 形式からストリームをロード」など。

solidに関するこの電子ブックをお勧めします。

トップダウンで設計しようとすると、「x の場合」、「y の場合」について繰り返し考えないように注意してください...最後に不要なものをたくさん追加するのは簡単すぎるためです。再利用可能な方法でモデル化されていません（それが追加した理由であっても...）。

于 2009-12-01T07:10:41.120 に答える
0

うーん。これが役立つかどうかはわかりませんが、Z 表記法を見たことがありますか? 大学で聞いたことがありますが、使用したことはありません (そのモジュールは使用しませんでした)。

于 2009-11-25T12:06:12.367 に答える