1はじめに
「3つのノー」と呼ぶことができるソフトウェアが多すぎます。つまり、要件もデザインもコメントもありません。厳密に言えば、それらの要件と設計は実際にはそこにありますが、文書化されていませんが、コメントは実際にはありません。これらのソフトウェアは大規模から小規模まで利用できますが、すべて共通の機能、つまり「保守が難しい」という機能があります。
数日前に同僚とチャットしたところ、XAMLの実装が書き直され、ローカルプロトコルに置き換えられると聞いたので、XAMLとの互換性を検討しました。このプロジェクトのコードは見たことがありませんが、このプロジェクトは基本的に「三不政策」であることを知っています。
もちろん、この状況もスリー・ナッシングの大きな特徴のひとつです。つまり、前足を離した後、後足が「理解できず、動かせない」ということです。その結果、書き直すほど簡単ではありません。 。
従業員の観点からはもちろん問題はありませんが、会社や製品の観点からは「無意味な損失」です。
自分自身に要件があるプログラマーは、「三不政策」プロジェクトを作成しないようにする必要があります
「標準化」は、プロジェクトの「三不政策」の問題を解決することができます。ネチズンの中には、ある予約システムのプロジェクトを始めた人もいたので、この例を参考にして、自分のデザインのアイデアをみんなに報告したり、社内での授業の準備をしたりしました。
2.デザインについて
ソフトウェア設計プロセスは、実際には派生プロセスです。プロセスの各ステップには、改良、検証、補足など、さまざまな関係があります。
以前デザインを勉強していた時、教科書を見て「トップダウン」「ボトムアップ」で段階的にシステムをデザインできると思っていたのですが、間違っていることに気づきました。デザインを勉強している友達もそう感じるべきだと思います。
コンピュータと人間の脳の最大の違いは、前者は線形システムであり、後者は非線形システムであるということです。いわゆる非線形性とは、一般的な見方では、頭を逆さまにして弓を左から右に開くことです。文学や芸術の観点からは、「スパイラルアップ」に注意を払っています。 、それは「機械的」「一回限り」の行動を意味します。人間の脳は天才を除いてそれが得意ではありません。
同じことがデザインにも当てはまります。それはもともと人間の脳の処理結果であるため、そのプロセスは非線形になるはずです。設計方法は、習得と受け入れを容易にするために、それ自体が「スパイラル」改善、つまりDeminghuanのPDCAプロセス（Plan-Do-Check-Adjust）を含むメカニズムである必要がありますが、設計プロセスでは計画要因は明らかではなく、主にDCAのプロセスです。
システム設計の過程で最大の気持ちは、自分を制限しないことです。設計を完成させて「トップダウン」の要件を満たすために、深く考えないように意図的に制限したことを覚えています。その結果はもちろん失敗でした。
もちろん、「制限」は、今述べた思考レベルの限界であるだけでなく、さらに重要なことに、ツールの限界を打ち破ります。すべてのツールは思考を制限し、作業の進行さえも制限します。
これまでのところ、最高のデザインツールはまだ「消しゴム付きの鉛筆」と「紙」なので、それをうまく利用する必要があります。
3.需要
特定のチケット予約システムは、現在最も有名で認知されているWebサイトであり、人間とコンピューターの相互作用の経験が乏しいです。それよりも優れたシステムを作成するにはどうすればよいですか。答えは「もっと慎重に設計する」です。
「より慎重に」設計する前に、要件を「より慎重に」収集する必要があります。
ソフトウェアの需要は、ソフトウェアが達成したい「目的」です。
「要件」を「要件ドキュメント」として言及しないでください。ドキュメントは、要件の表現の単なる形式です。もう1つの一般的な表現の形式は、プログラマーの頭脳の記憶です。
安っぽいプログラマーは、要件を口から渡すことがよくあります。一度にすべてを書くのに少し時間を費やすのではなく、何度も何度も言うのに苦労します。顧客の変化する要件に何度も耐えることはできませんが、彼らが毎回言うことを気にしないでください。同じ要求は少し形が崩れています。
3.1。最初のステップ：ユースケースの階層化
ここでは、UMLユースケース図（UseCase）を使用して要件を表します。
ユースケース図も階層的に説明されています。すべてのシステムのトップレベルのユースケース図（ゼロレベルのユースケース）は類似しており、多くの役割を囲む円があります。違いは、役割の数と円に書かれている単語が異なることです。
今回はサークル内に「チケット予約システム」を作成しましたが、周辺の役割はユーザーと管理者の2つだけです。
第1レベルのユースケース図は完全に異なります。私はそれを7つの部分に分けました。それに含まれる第1レベルのユースケース名と第2レベルのユースケース名は次のように説明されています。
- ユーザー管理：登録、ログイン、ログアウト、パスワード検索、情報ビュー、情報変更、ユーザー検証、ユーザークエリ
- お問い合わせ：時刻表、残りのチケット、接続計画、遅延
- 注文：注文、注文のキャンセル、注文の変更、注文のクエリ、予約
- 発券：チケット予約、チケット収集、変更、返金、チケットクエリ
- 資金：支払い、返金、小切手到着、銀行照合
- チケットプール：チケットエントリ、チケット発行、チケットプールクエリ、チケットプールの変更
- メンテナンス：パラメータ設定、辞書のメンテナンス、トポロジ管理、ログクエリ、バックアップ、リカバリ
上記のリストは、誰もが読みやすいように記載されています。実際、私もこの概要を使用して考えています。補足図は次のとおりです
。もちろん、上記の部分は初期状態でも最終状態でもありませんが、多くの調整と改善を経た現在の状態であり、今後の分析に応じてさらに調整される予定です。さらに、システムのユースケース表現は一意ではなく、異なる人々によって与えられるユースケースは異なることに誰もが注意する必要がありますが、理論的にはそれらは同等である必要があります。
ユースケース図の各部分は、実際の顧客志向である必要があります。それが説明する最小単位は、ビジネスモジュールである必要があります。
ユースケースを判断する基準は「ビジネスの重要性」です。いわゆる「ビジネスの重要性」とは、ビジネスモジュールが完了した後、ビジネスまたはビジネスプロセス全体を進めることができることを意味します。この「プロモーション」の結果には、役割の変更または目標変更。
上記の定義から、「funds。Querytoaccount」および「ticketpool。locktickets」はユースケースではない可能性があります。この記事を書くまで、私はまだ躊躇していましたが、これら2つのユースケースがビジネスを前進させることができるのは事実ですが、外部に関連するアクターがないため、後で除外することにしました。
このことから、最初と2番目のユースケースでは、内部モジュールまたはシステムとしてアクターを使用しないことが最善であることも学びました。
ソフトウェアテスト交換グループ：785128166
WeChatパブリックアカウント：プログラマーErhei;注意を払った後、無料で一連のビデオリソースを受け取ることができます;詳細に説明します：Python自動テスト、Web自動化、インターフェイス自動化、モバイル端末自動化、インタビュー体験およびその他の関連コンテンツ、学習リソースはあなた次第ですアクション、「コレクター」にならないでください
次の更新：便のテストケース
機能テスト用に選択された乾物のコレクションは次のとおりです。