- サブジェクトエリアの分析とTKの作成（顧客との対話）
- プログラム構造設計
- コーディング（プロジェクトのドキュメントに従った一連のプログラムコード）
- テストとデバッグ
- プログラムの実施
- プログラムサポート
- 廃棄
設計プロセスについて詳しく説明します。 設計プロセス中に、アーキテクトまたは経験豊富なプログラマーが、テキストの説明、図、将来のプログラムのモデルを含むプロジェクト文書を作成します。 この難しい問題では、UML言語が役立ちます。
UML-さまざまなシステム（特にプログラム）の視覚化、パラメーターの説明、設計、文書化のためのグラフィック言語です。 グラフは、Rational Rose（http://www-01.ibm.com/software/rational/）やEnterprise Architect（http://www.sparxsystems.com.au/）などの特別なCASEツールを使用して作成されます。 UMLテクノロジーに基づいて、単一の情報モデルが構築されています。 上記のCASEツールは、さまざまなオブジェクト指向言語でコードを生成でき、非常に便利なリバースエンジニアリング機能を備えています。 （リバースエンジニアリングを使用すると、既存のプログラムコードとそのコメントからグラフィカルモデルを作成できます。）
モデルを視覚化するためのダイアグラムのタイプを検討します（これは必須ですが、さらに多くのタイプがあります）。
- ユースケース図
- クラス図
- ステートチャート図
- シーケンス図
- コラボレーション図
- コンポーネント図
- 展開図
ユースケース図
設計されたシステムは、いわゆる先例を使用してシステムと対話する多くのエンティティまたはアクターの形で表されます。 この場合、アクターまたはアクターは、外部からシステムと対話するエンティティです。 言い換えれば、各ユースケースは、アクターとの対話でシステムによって実行されるアクションの特定のセットを決定します。 同時に、アクターとシステムとの相互作用がどのように実現されるかについては何も言われていません。
クラス図
クラス図は、オブジェクト指向プログラミングのクラスの用語でシステムモデルの静的構造を表すのに役立ちます。 クラス図は、特に、オブジェクトやサブシステムなど、ドメインの個々のエンティティ間のさまざまな関係を反映することができ、それらの内部構造（フィールド、メソッドなど）および関係のタイプ（継承、インターフェイスの実装など）も説明します。 この図は、システムの機能の時間的側面に関する情報を示していません。 この観点から、クラス図は、設計されたシステムの概念モデルをさらに発展させたものです。 この段階では、基本的にOOPアプローチと設計パターンの知識が必要です。
ステートチャート図
この図の主な目的は、ライフサイクル中のモデル要素の動作を一緒に特徴付ける状態と遷移の可能なシーケンスを記述することです。 状態図は、特定の特定のイベントの認識に対する反応の仕様に基づいて、エンティティの動的な動作を表します。
シーケンス図
UML言語でオブジェクトの相互作用をモデル化するために、適切な相互作用図が使用されます。 オブジェクトの相互作用は時間内に考慮することができ、シーケンス図を使用して、オブジェクト間のメッセージの送受信の時間的特徴を表します。 相互作用するオブジェクトは互いに情報を交換します。 この場合、情報は終了したメッセージの形式を取ります。 つまり、メッセージには情報コンテンツが含まれていますが、受信者に指示された影響を与えるという追加のプロパティを取得します。
コラボレーション図
長方形の形の協調図は、オブジェクトの名前、そのクラス、および場合によっては属性値を含む対話に参加しているオブジェクトを示します。 クラス図のように、オブジェクト間の関連付けはさまざまな接続線の形で示されます。 この場合、関連付けの名前と、この関連付けでオブジェクトが果たす役割を明示的に指定できます。
シーケンス図とは異なり、協調図は、相互作用で特定の役割を果たすオブジェクト間の関係のみを示します。
コンポーネント図
コンポーネント図は、前述の図とは対照的に、システムの物理的表現の特徴を説明しています。 コンポーネント図を使用すると、ソース、バイナリ、実行可能コードなどのソフトウェアコンポーネント間の依存関係を確立することにより、開発したシステムのアーキテクチャを決定できます。 多くの開発環境では、モジュールまたはコンポーネントはファイルに対応しています。 モジュールを接続する破線の矢印は、ソースプログラムのコンパイル時に発生する相互依存関係に類似した相互依存関係を示しています。 コンポーネント図の主要なグラフィック要素は、コンポーネント、インターフェース、およびそれらの間の依存関係です。
展開図
配置図は、ランタイム段階でのみ存在するプログラム要素とコンポーネントの視覚化を目的としています。 この場合、実行可能ファイルまたは動的ライブラリであるプログラムのコンポーネントインスタンスのみが表示されます。 実行時に使用されないコンポーネントは、展開図には表示されません。
展開図には、プロセッサ、デバイス、プロセス、およびそれらの間の関係のグラフィカルな表現が含まれています。 論理的なプレゼンテーション図とは異なり、展開図は実装の機能を完全に反映する必要があるため、システム全体で統一されています。 実際、この図は特定のソフトウェアシステムのOOAPプロセスを完了し、その開発は原則としてモデル仕様の最終段階です。
これで、特に図と設計全般の概要ツアーを終了します。 設計プロセスが長い間ソフトウェア開発の標準になっていることは注目に値しますが、多くの場合、美しく書かれたプログラムに対処する必要があります。これは、通常のドキュメントがないため、不要なサイド機能、松葉杖に囲まれ、面倒になり、以前の品質を失います。 =（
プログラマーは主にエンコーダーであると確信しています-彼は顧客と通信してはならず、システムアーキテクチャについて考えてはならず、プログラムへのインターフェースを発明してはならず、コーディングするだけです-アルゴリズム、機能、外観、ユーザビリティを実装するだけで、 ... 設計者は、抽象図（サブジェクト領域の説明）から始めて、データの構造、クラス、およびそれらの相互作用のプロセスを表す図まで、すべてを段階的に詳細にペイントする必要があります。 つまり、作業の複雑さと設計者の給与は、プログラマー==エンコーダーよりも1桁高くなければなりません。 扇動でごめんなさい....