ソフトウェアデザイナー (オブジェクト指向、UML、デザインパターン)

オブジェクト指向

• 親切
  • クラスはオブジェクトの抽象化であり、オブジェクトはクラスのインスタンスです
  • エンティティクラス
    • コアクラス (現実世界の実際のエンティティ)
  • インターフェースクラス（境界クラス）
    • ユーザーがシステムと協力して対話する方法を提供します (システム内外の参加者との連絡手段)
  • コントロールクラス
    • コーディネーター (クラス オブジェクト間の相互作用を調整する) として機能し、アクティビティのフローを制御します。
  • クラス一般（乗り物） 特別な関係（船、自動車、飛行機） ps は、大きな範囲が小さな範囲を含むことを意味します
• 物体
  • オブジェクトは、データ (プロパティ、状態)、およびデータに対する操作 (サービス、動作、メソッド) を含む基本的なエンティティです。
  • これは、オブジェクト名、属性、メソッドの 3 つの部分で構成されます。
  • オブジェクト間で通信するための構造はメッセージと呼ばれます
• メソッドのオーバーロード: クラスには、名前は同じでパラメーターの型が異なる複数のメソッドを含めることができます。
  • メソッド名は同じですがパラメータの数が異なります
  • メソッド名は同じですがパラメータの型が異なります
  • 同じパラメータの型の順序を持​​つメソッド名が異なります
• メッセージ: オブジェクトによって発行されるサービス リクエスト。相互通信を提供します。
• カプセル化
  • オブジェクトは、属性と動作を全体としてカプセル化するものであり、情報隠蔽技術です。1 つのインターフェイスのみが公開されます
• 継承する
  • 親クラス (スーパークラス、基本クラス) とサブクラス (派生クラス) の間でデータとメソッドを共有するためのメカニズム
  • 親クラスは複数のサブクラスを持つことができ、1 つの親クラスのみからの継承は単一継承、複数の継承は多重継承です。
  • 子は拡張します 親と子は親のメソッドをオーバーライドできます (オーバーライド、置換)
• 多態性
  • 異なるオブジェクトが同じメッセージを受信し、まったく異なる結果を生成します。継承の受け取りのサポートを実装します。
  • 親クラス名 オブジェクト名 = 新しいサブクラス名 () コンパイル (静的バインディング) は左を見て、実行 (動的バインディング) は右を見てください。
  • ジェネリック多態性
    • パラメトリック多態性: 最も広く使用されている多態性、最も純粋な多態性
    • 包含ポリモーフィズム: 多くの言語では、ある型が別の型のサブタイプになります。
  • 特定の多型性
    • オーバーロードのポリモーフィズム: 同じ名前でも、コンテキストが異なれば異なる意味を持ちます。
    • 必須のポリモーフィズム
• オブジェクト指向設計の原則
  • 単一責任の原則: クラスに関する限り、クラスを変更する原則は 1 つだけであるべきです。
  • オープンクローズの原則: 拡張の場合はオープン、変更の場合はクローズ
  • リスコフ置換原則: サブクラスは基本クラスが出現する場所に出現しなければなりません
  • 依存関係逆転の原則: 抽象化は詳細に依存すべきではなく、詳細は抽象化に依存すべきであり、高レベルのモジュールは低レベルのモジュールに依存すべきではありません (詳細 (実装) ではなく抽象化に依存します)
  • インターフェイス分離の原則: 具体性ではなく抽象性に依存する
  • 共通の再利用原則: パッケージ内のクラスを再利用する場合は、パッケージ内のすべてのクラスを再利用する必要があります。
  • 共通のクロージャ原則: 変更が 1 つのクラスに影響を与えると、その変更はパッケージ内のすべてのクラスに影響しますが、他のパッケージには影響がありません。
• オブジェクト指向分析 OOA
  • 目的はアプリケーションの問題を理解することであり、理解の目的はシステムの機能要件とパフォーマンス要件を決定することです。
  • 五つのステップ
    • 識別オブジェクト
      • 問題領域を定義（決定）する際には、自然に発生する「名詞」をオブジェクトとして扱います
    • 組織オブジェクト
    • オブジェクト間のインタラクション（オブジェクト間のインタラクション）を説明する
    • オブジェクトの操作を決定する（オブジェクトベースの操作）
    • オブジェクトの内部情報を定義する
• オブジェクト指向設計 OOD
  • OOAで作成した解析モデルを設計パターンに変換します。目標は、システム アーキテクチャの青写真 (モデル図) を定義することです。
  • ソリューションを理解し、システムの詳細を実装する
  • OOA に対応する 5 つのアクティビティ: クラスとオブジェクトの識別、属性の定義、サービスの定義、関係の識別、およびパッケージの識別
• オブジェクト指向プログラミング OOP
• オブジェクト指向テストの 4 つのレベル: アルゴリズム層、クラス層、テンプレート層、システム層
• 拡大
  • クラスの静的メソッドは、そのクラスの静的メンバー変数にのみアクセスできます。
  • 静的データ メンバーには、クラスのすべてのメソッドからアクセスできます。
  • このクラスのオブジェクトは静的メンバーの値を共有します
  • オブジェクトには明確な境界、明確に定義された動作、および拡張性があります。
  • ドメイン クラス モデルには、属性、操作、および関連付けが含まれています

UML 統一モデリング言語

• UML の構成要素
  • モノとは、モデルの最も代表的なコンポーネントを抽象化したものです
    • 構造的なもの (名詞 static): クラス、インターフェース、コラボレーション、ユースケース、アクティブクラス、コンポーネント、アーティファクト、ノード
    • 行動的なもの (動詞力学): インタラクション (メッセージ)、ステートマシン (状態)、アクティビティ (アクション)
    • ものをグループ化する (整理セクション): パッケージ、ものに注釈を付ける (説明セクション): 注釈
  • 関係が物事を結びつける
  • グラフは関連するものを集めます
  • UML インターフェースを使用して、オブジェクト クラスに必要なサービスを宣言できます。
• UML における 4 つの関係
  • 依存関係: 独立したもの A の変更は、別の依存するもの B---->A のセマンティクスに影響を与えます。点線は次のことを表します。
  • 関連: オブジェクト間の接続であるチェーンのセットを記述する構造的な関係。
    • この関係は直線であり、その上で多重度 (反復性) と役割 0...1—0...* 1 対多をマークできます。
    • 多対多では関連クラス (新しいクラス) を作成する必要があります。
    • 集約: 全体と部分の間の構造的な関係を記述する特別なタイプの関連付け
      • 集約:—◇ ライフサイクル全体の一部が矛盾しており、全体が消滅し、一部がまだ存在しており、全体がなくても一部が存在する可能性があります。
      • 組み合わせ：—◇（固体）部分の全体的なライフサイクルは同じで、全体は消滅し、部分も消滅し、部分は全体なしでは存在できません。
  • 関係: 子要素 (特殊要素) のオブジェクトは親要素 (一般要素) のオブジェクトを置き換えることができ (クラスと複数のクラス間の関係)、子要素は親の構造と動作を共有します。 : 親要素を指す中空矢印の実線 (pan )
  • 実現: 分類子は、別の分類子によって実行されることが保証された機会を指定します。図は次のとおりです。中空の矢印が付いた点線、クラスはインターフェイスを指します。
• UML図

  • クラス図

    • 一連のオブジェクト、インターフェイス、コラボレーション、およびそれらの間の関係を示す最も一般的な図
    • 先行する修飾子: +public-private#protected~package's
    • システムの静的設計ビューをモデル化するために使用され、ビューは機能要件をサポートし、3 つのモデリング方法はクラス図を使用します。
      • システムの語彙のモデル化、単純なコラボレーションのモデル化、論理データベース スキーマのモデル化

  • オブジェクトグラフ

    • オブジェクトのグループと、特定の瞬間におけるオブジェクト間の関係。インスタンスの静的スナップショットを記述します。通常はオブジェクトとチェーン グラフが含まれます。 オブジェクト名: クラス名属性 (通常は値を持ちます)。メソッドはありません。

  • ユースケース図

    • システムの静的なユースケースビューをモデル化する場合: システムのコンテキストをモデル化し、システムの要件をモデル化する
    • 一連のユースケース、アクター、およびそれらの関係を示します (ユースケースを表す図は楕円です)。
      • ユースケースとユースケースの間には拡張および包含の関係があります
        • 基本的なユース ケース (ユース ケースを含む) - "include" –> B は、含まれるユース ケースが A を実行する前に実行する必要があります。
        • ユースケースが実行されると、このユースケースの拡張ユースケースであるいくつかの特別な状況またはオプションの状況が発生することがあります。
          • 拡張ユースケース（特殊なケース）----《extend》—>基本的なユースケース
      • ユースケースとユースケースとアクターの間の一般化。
        • 図は次のとおりです。実線と中空の矢印。子クラスは親要素を指します。
      • アクターとユースケース間の関連性

  • インタラクティブな図

    • システムの動的な側面、つまりシステム間のメッセージの受け渡しをモデル化します。インタラクション図には通常、オブジェクト、チェーン、メッセージが含まれており、シーケンス図やコミュニケーション図として表されます。
      • シーケンス図 (シーケンス図): 時系列順に編成されたオブジェクト間の対話アクティビティを説明するシーンのグラフィック表現。インタラクティブ オブジェクトはグラフの上部、インタラクションが開始される左側、および下位オブジェクトの右側に配置されます。
        • シーケンス図にはオブジェクトのライフラインがあり、垂直の点線で表され、一定期間内にオブジェクトが存在することを示します。X はライフラインが消える (終了する) ことを意味します
        • シーケンス図にはコントロール フォーカスがあり、細長い長方形で表されます。これは、オブジェクトがアクションを実行する期間 (オブジェクト相互作用の期間) を表し、直接または下位レベルを通じて実行できます。プログラム。
        • メッセージ—> <------ メッセージを同期的に返す メッセージが非同期的に返されるのを待つ必要がある 必要はない
      • 通信図 (コラボレーション図): メッセージを送受信するオブジェクトの構造的構成を強調します (オブジェクト間のメッセージ フローとシーケンスを示します)。
        • 通信グラフには、あるオブジェクトが別のオブジェクトにどのようにリンクされているかを示すパスがあります。
        • コミュニケーション図には、あいまいなメッセージの時系列順序を示すシーケンス番号が付いています。

  • 状態図

    • 状態、遷移、イベント、アクティビティで構成されるステート マシンを表します。システムの動的なビューに焦点を当て、オブジェクトの動作におけるイベントのシーケンスを強調します。リアクティブ オブジェクト モデリング (オブジェクト)

      • 状態は、状態の変更とアクションの実行の両方が可能なシステム動作の観察可能なパターンです。状態には、初期状態 (黒い点)、最終状態 (黒い点と円)、中間状態があります。

      • 状態図は丸い四角形 (その後、上、中、下に分割されます) で、上の部分は状態名 (必須)、中央の部分は状態変数の名前と値 (オプション)、そして下の部分です。部分はアクティビティ テーブル (オプション) 状態間の状態遷移、始まりは点火またはトリガー、初期状態は最終状態を 1 つだけ持つことができ、複数またはなし

      • アクティビティ図 = アクティビティ = 複数のアクション: イベント名 (PS が鳴る) / アクション式 (PS が電話に出る)

        • 3 つの標準的なイベント名
          

      • 変換 (移行): 状態間の状態遷移は矢印付きの線で表されます。

        • 2 つの状態があります 元の状態 ===== "ターゲット状態

      • イベント (変換をトリガーします): これは、変換ロゴ上のイベントであり、特定の瞬間に発生するものであり、システム動作をある状態から別の状態に変化させる外部イベントを抽象化します。

        • 式：イベント説明[ガーディアン条件]/アクション式
          • イベントの説明とガード条件 (ブール値) を同時に使用すると、イベントが発生し、条件が true の場合にのみ、状態遷移が発生します。
          • 監視条件 (ブール値) のみがあり、イベントの説明がない場合、条件は true となり、状態が遷移するときにアクション式が発生します (イベントがマークされていない場合は、内部アクティビティの終了後に自動的に切り替わります)。

      • アクティビティ (アクション) は、状態内または状態遷移 (トランジション) で実行できます。

      • 複合状態 (スーパーステート) にはネストされた状態 (サブステート) が含まれます

  • アクティビティ図

    • あるアクティビティから別のアクティビティに流れる特別な種類の状態図。(状態との違いは、実線矢印に時間がなく、[]ガーディアン表現のみであること)
    • ワークフローのモデリング、操作のモデリング、アクティビティ図の 2 つの使用方法

  • アーキテクチャ図（コンポーネント図）

    • 一連のコンポーネント間の構成と依存関係。クラス図に関連する静的実装ビュー。コンポーネントが 1 つ以上のクラス、インターフェイス、およびコラボレーションにマップされます。
      

  • 展開図

    • オブジェクト指向の物理的側面を、コンポーネント図に対して (ステレオ) 静的にモデル化する方法
    • 実装段階で使用される、システムのソフトウェアとハ​​ードウェアの関係を示します。
    • デプロイメントコンポーネント間の依存関係はパッケージの依存関係に似ています

  • 要約する
    

デザインパターン

• デザインパターンの要素

  • 関連する問題に対する解決策を提供し、人々が成功した設計とアーキテクチャをより簡単かつ便利に再利用できるようにします。
  • 4つの要素: モデル名、問題点、解決策、効果
  • 各設計パターンは、特定のオブジェクト指向設計の問題または設計ポイントに焦点を当てています。
    

• 創造的なデザインパターン

  • さまざまな種類の情報がカプセル化されており、システム全体がこれらのオブジェクトについて認識しているのは、抽象ロックによって定義されたインターフェイスです。
  • ファクトリ メソッド パターン (クラス)
    • その目的は、オブジェクトを作成するためのインターフェイスを定義し、どのクラスをインスタンス化するかをサブクラスに決定させ、ファクトリ メソッドでクラスのインスタンス化をそのサブクラスに延期することです。
    • クラスが作成するオブジェクトのクラスを知らない場合、およびクラスが作成するオブジェクトをそのサブクラスに指定する必要がある場合に適用されます。
  • 抽象的な工場パターン
    • その目的は、具体的なクラスを指定せずに、一連の関連オブジェクトまたは相互依存オブジェクトを作成するためのインターフェイスを提供することです。
    • システムがその製品の作成、構成、プレゼンテーションから独立している場合
    • システムを複数の製品ファミリーのいずれかで構成する場合
    • 関連する一連の商品オブジェクトのデザインを重視して共同利用したい場合
    • 製品クラスのライブラリを提供し、その実装ではなくインターフェイスのみを表示したい場合
    • ps: 抽象ファクトリに適した、グラフィカル ユーザー インターフェイス コンポーネントのさまざまなプラットフォーム用の並列クラス階層を定義します。
  • ジェネレーターパターン
    • 複雑なオブジェクトのコンポーネントをその表現から分離し、同じ構築プロセスで異なる表現を作成できるようにする
    • 複雑なオブジェクトを作成するアルゴリズムが、オブジェクトの構成要素とその組み立て方法から独立している必要がある場合に適用されます。
    • 構築手順で、構築されるオブジェクトのさまざまな表現を許可する必要がある場合
  • プロトタイプパターン
    • その目的は、プロトタイプ インスタンスが作成するオブジェクトの種類を指定し、これらのプロトタイプを複製することによって新しいオブジェクトが作成されることです。
    • システムをその製品とは独立して作成、構築、表現する必要がある場合に適用可能
    • 動的ロードなどにより、インスタンス化するクラスが実行時に指定される場合
    • 次の場合に、製品クラス階層と並行してファクトリ クラス階層を作成しないようにするには、
    • クラスのインスタンスが、複数の異なる状態の組み合わせのうち 1 つだけを持つことができる場合、適切な状態で毎回クラスを手動でインスタンス化するよりも、対応する数のプロトタイプを作成してクローンを作成する方が便利な場合があります。
  • シングルトンパターン
    • その目的は、クラスにインスタンスが 1 つだけあることを確認し、そのインスタンスへのグローバル アクセス ポイントを提供することです。
    • クラスがインスタンスを 1 つだけ持つことができ、クライアントが既知のアクセス ポイントからそのインスタンスにアクセスできる場合に適用されます。
    • 唯一のインスタンスをサブクラス化する必要があり、クライアントはコードを変更せずに拡張インスタンスを使用できる場合

• 構造作成パターン

  • クラスとオブジェクトを結合してより大きな構造を取得し、継承メカニズムを使用してインターフェイスまたは実装を結合する方法

  • アダプター パターン (クラス)

    • クラスのインターフェイスをクライアントが必要とする別のインターフェイスに変換します。アダプター モードを使用すると、互換性のないインターフェイスのために連携できなかったクラスが連携できるようになります。
    • インターフェースが要件を満たしていない既存のクラスを使用したい
    • 他の無関係なクラスや予期しないクラスと連携して動作する再利用可能なクラスを作成したい（理解）
    • 既存のサブクラスを使用したいが、インターフェイスに一致するようにそれぞれをサブクラス化することは不可能です。オブジェクト アダプターはそのスーパークラス インターフェイスを適応させることができます (オブジェクトのみ)

  • ブリッジモード

    • 抽象部分をその実装から分離して、両方が独立して変更できるようにする
      

  • コンビネーションモード

    • オブジェクトをツリー構造に結合して「部分-全体」階層を表現すると、ユーザーは単一オブジェクトの結合オブジェクトを一貫して使用できるようになります。
    • オブジェクトの部分全体の階層を表現したい場合に適しています
    • ユーザーが複合オブジェクトと単一オブジェクトの違いを無視し、複合構造内のすべてのオブジェクトを均一に使用することが望まれます。

  • デコレータパターン

    • その目的は、オブジェクトに追加の責任を動的に追加することです。
    • 他のオブジェクトに影響を与えることなく、動的かつ透過的に個々のオブジェクトに責任を追加します。
    • 取り消される可能性のある責任に対処する

  • 外観モード

    • その目的は、サブシステムの一連のインターフェイスに一貫したインターフェイスを提供することです。
    • 複雑なサブシステムにシンプルなインターフェースを提供したい場合
    • クライアントプログラムと抽象クラスの実装部分の間には大きな依存関係があります
    • 階層サブシステムを構築する必要がある場合、それを使用してサブシステム内の各層のエントリ ポイントを定義します。

  • フライウェイトモード

    • その目的は、共有技術を使用して、多数のきめの細かいオブジェクトを効率的にサポートすることです。
    • アプリケーションは多数のオブジェクトを使用します
    • 完全にオブジェクトの数が多いため、ストレージのオーバーヘッドが大きくなります
    • オブジェクトのほとんどの状態は外部状態になる可能性があります
    • オブジェクトの外部遷移が削除されると、多くのオブジェクト グループを比較的少数の共有オブジェクトに置き換えることができます。

  • プロキシモード

    • その目的は、他のオブジェクトにプロキシを提供して、このオブジェクトへのアクセスを制御することです。
      

• 行動デザインパターン

  • アルゴリズムとオブジェクト間の責任の割り当てを設計し、オブジェクトとクラスのスキーマ、およびそれらの間の通信スキーマを説明します。
  • 通訳モード
    • その目的は、言語が与えられた場合に、その文法の表現を定義し、この表現を使用してその言語の文を解釈するインタプリタを定義することです。
    • 言語を解釈して実行する必要があり、その言語の文を抽象構文ツリーとして表現できる場合
    • 文法は単純で効率は重要な問題ではない
  • テンプレートメソッドパターン
    • その目的は、一部のステップをサブクラスに延期しながら、操作内のアルゴリズムのスケルトンを定義することです。テンプレートを使用すると、アルゴリズムの構造を変更せずに、サブクラスでアルゴリズムの特定のステップを再定義できます。
    • アルゴリズムの定数部分を一度に実装し、変数の動作はサブクラスに任せます
    • コードの重複を避けるために、サブクラス間で共通する動作は抽出され、共通の親クラスに集中化される必要があります。
    • 制御サブクラス拡張
  • 責任連鎖モデル
    • インテントは、複数のオブジェクトにリクエストを処理する機会を与えることで、リクエストの送信者と受信者の結合を回避します。これらのオブジェクトをチェーンにリンクし、オブジェクトが処理するまでチェーンに沿ってリクエストを渡します。
    • リクエストを処理できるオブジェクトは複数あり、どのオブジェクトがリクエストを処理するかは実行時に自動的に決定されます。
    • 受信者を明示的に指定せずに、複数のオブジェクトの 1 つにリクエストを送信したい
    • リクエストを処理できるオブジェクトのセットは動的に指定する必要があります
  • コマンドモード
    • その目的は、リクエストをオブジェクトにカプセル化して、さまざまなリクエストを使用してクライアントをパラメータ化し、リクエストを処理したり、リクエスト ログを記録したり、取り消し可能な操作をサポートしたりできるようにすることです。
    • 実行するアクションを抽象化し、オブジェクトをパラメータ化します。
    • リクエストをさまざまなタイミングで指定、キューに入れ、実行する
    • サポートキャンセル操作サポート変更ログ
    • 原始的な操作をベースにした高度な操作を備えたシステムを構築する
  • イテレータパターン
    • その目的は、オブジェクトの内部表現を公開することなく、集合オブジェクトの要素に順次アクセスする方法を提供することです。
    • 内部表現を公開せずに集約オブジェクトの内容にアクセスする
    • 集約されたオブジェクトの複数の走査をサポートします
    • さまざまな集計構造を横断するための共通インターフェイスを提供します
  • メディエーターパターン
    • その目的は、中間オブジェクトを使用して一連のオブジェクトの対話をカプセル化することです。
    • オブジェクトのセットは、明確に定義されているものの複雑な方法で通信するため、相互依存関係が構造化されておらず、理解が困難になります。
    • オブジェクトは他の多くのオブジェクトを参照し、これらのオブジェクトと直接通信するため、オブジェクトの再利用が困難ですか?
    • あまり多くのサブクラスを生成せずに、複数のクラスに分散される動作をカスタマイズしたい
  • メモモード
    • その目的は、カプセル化を破ることなくオブジェクトの内部状態をキャプチャし、この状態をオブジェクトの外部に保存して、後でオブジェクトを元の保存された状態に復元できるようにすることです。
    • 特定の時点でのオブジェクトの状態は、後で必要になった場合に以前の状態に復元できるように保存する必要があります。
    • インターフェイスを使用して他のオブジェクトがこれらの状態を直接取​​得できるようにすると、オブジェクトの実装の詳細が公開され、オブジェクトのカプセル化が破壊されます。
  • オブザーバーパターン
    • その目的は、オブジェクト間の 1 対多の依存関係を定義することです。オブジェクトの状態が変化すると、それに依存するすべてのオブジェクトが通知され、自動的に更新されます。
    • 抽象モデルに 2 つの側面があり、一方が他方に依存している場合は、その 2 つを個別のオブジェクトにカプセル化して、独立して変更および再利用できるようにします。
    • 1 つのオブジェクトを変更するときに他のオブジェクトも同時に変更する必要があり、変更する必要があるオブジェクトの数が正確に不明な場合
    • オブジェクトが他のオブジェクトに通知する必要があるが、他のオブジェクトが誰であるかを想定できず、これらのオブジェクトが密結合されることも望まない場合
  • ステートモード
    • その目的は、オブジェクトの内部状態が変化したときにオブジェクトの動作を変更できるようにすることです。オブジェクトはそのクラスを変更したようです
    • オブジェクトの動作はその状態によって決定され、実行時に状態に基づいて動作を変更する必要があります。
    • 操作には巨大な複数分岐の条件文があり、これらの分岐はオブジェクトの状態に依存します。この状態は多くの場合、1 つ以上の列挙定数によって表されます。
  • 戦略パターン
    • その目的は、一連のアルゴリズムを定義し、それらを 1 つずつカプセル化し、交換可能にすることです。このモードでは、アルゴリズムを使用するクライアントとは独立してアルゴリズムを変更できます。
    • 関連するクラスの多くは動作が異なるだけです
    • アルゴリズムのさまざまなバリエーションを使用する必要がある
    • アルゴリズムはクライアントが知ってはならないデータを使用します
    • クラスはさまざまな動作を定義します。この動作は、このクラスの操作において複数の条件ステートメントの形式で表示され、関連する条件分岐がそれぞれのストラテジ クラスに移動されて、これらの条件ステートメントが置き換えられます。（ジュニア会員、中級会員、シニア会員は割引率が異なります）
  • 訪問者のパターン
    • インテントは、オブジェクト構造内の要素に対して実行される操作を表します。クラスを変更せずに要素に対する新しい操作を定義します。
    • オブジェクト構造には、さまざまなインターフェイスを持つ多くのクラス オブジェクトが含まれており、ユーザーはこれらのオブジェクトに対して、特定のクラスに依存する操作を実行したいと考えています。
    • オブジェクト構造を定義するクラスはほとんど変更されませんが、多くの場合、この構造に対する新しい操作を定義する必要があります。
    • オブジェクト構造内のオブジェクトに対して、無関係なさまざまな操作を実行する必要がある