ソフトウェアエンジニアリング - 開発と設計

プランUML

オープンソース ツール、簡単なテキスト記述を使用して UML 図を描画、公式 Web サイトのアドレス: https://plantuml.com/zh/

UML

アソシエーションは、あるクラスが別のクラスのプロパティとメソッドについて知ることを可能にする所有権関係です。集計関係は関連関係、つまり強い関連関係です。関連と集計は構文的に区別できず、特定の論理関係をチェックする必要があります。しかし、全体がなければ部分は単独で存在することはできません。構成関係は関連関係であり、集約関係よりも強力です。

コンテンツリファレンス:ソフトウェアエンジニアリング

1. UMLの概念モデル

UML には、完全かつ包括的な表現方法を提供する完全な概念モデルがあり、その主な要素には、 ① 、ルールこれらの構成要素がどのように組み合わされるかを規定する②、基本UML の。

2、UML 概念モデルの凡例

ここに画像の説明を挿入

3. UML の基本構成要素

UML では、語彙は 3 つの構成要素、つまり 3 種類の語彙または基本要素 (物、関係、図)に分割できます。

1. UML の内容

(1) UMLの4種類

モノとは、モデル内の最も代表的なコンポーネントを抽象化したもので、構造的なもの、動作的なもの、グループ化されたもの、および注釈的なものに分類できます。

1) 構造的なもの

通常、概念の物理的要素を記述するモデルの静的な部分です。構造的には主に次の 5 つがあります。

• クラス(class): オブジェクト指向アプローチにおけるクラスの概念と一致します。
• インターフェース(interface): クラスまたはコンポーネントのサービスの一連の操作を記述します。
• ユースケース(use case): システム機能を表し、特定の参加者 (つまり、システム ユーザー) にとって貴重で観察可能な結果を​​生み出す、システムによって実行される一連のアクションの説明です。
• コンポーネント(component): システム内のソフトウェアの物理的なものを記述します。
• ノード(node): 実行時に存在し、計算リソースを表す物理要素です。

2) 行動的なもの

行動的なものには主に状態と相互作用が含まれます。

3) 物事をグループ化する

グループ化には主にパッケージが含まれます。

4) 物事に注釈を付ける

注釈には主に次のものが含まれます。

(2) UMLでいろいろなことをグラフィカルに表現する方法

上記の 4 種類のものの説明に従って、UML でさまざまなものを図にすると、次のようになります。

2. UML における 4 種類の関係

UML の 4 つの関係は、依存関係、関連性、一般化、実現です。

(1) 依存性

2 つのモデル要素のうち、1 つは独立しており、もう 1 つは非独立です。独立したモデル要素を変更すると、独立していないモデル要素に影響します。

依存関係は、矢印付きの破線で示されます。

写真が示すように:

(2)協会

アソシエーションは、2 つのモデル要素が関連付けられる構造化された関係です。双方向の関連付けは実線で表されます。

注: 複数の程度の関連関係があり、主に0、1、0..1、0..*、が含まれます1..*。

写真が示すように:

アソシエーションには、 合成 と 集約 という2 つの特殊なタイプの関連付けがあることに注意してください。

複合タイプと集約タイプの場合は、ひし形の記号を追加します。

以下に示すように:

(3) 一般化

一般と特殊の関係、つまり継承の関係です。それは実線と白抜きの三角形で表されます。

写真が示すように:

(4) 実現する

実装関係は、あるモデル要素が別のモデル要素の実行を保証するというもので、この関係は主にインターフェースで使用されます。実線で表されます。

写真が示すように:

これら 4 つの関係を確認するために、全体像を以下に示します。

IDEA で UML 関係図を生成する

3. UML のグラフィックス (5 つのカテゴリと 10 個の図)

(1) ユースケース図

1) ユースケース図の定義

ユースケース図は、ユーザーの観点からシステム機能を説明し、各機能の演算子を示します。

ユースケース図は、いくつかの役割またはアクター (actor)と、これらの役割とシステムによって提供されるユースケースの間の関係を示します。ユースケース図は、システムの機能要件を定義します。

2) ユースケース図の基本構成

• 例;
• 役割;
• 役割間の関係 (存在する場合、ほとんどが一般化)。
• 役割とユースケースの間の関係 (一方向または双方向の関連付け)。
• ユースケースとユースケース間の関係 (包含、拡張、一般化)。

3) 要素間の関係

含む：

• include (包含関係) では、2 つ以上のユース ケースが同じアクションのセットを共有する場合、複数の基本ユース ケースで共有するための独立したサブ ユース ケースとして抽出できます。
• 基本ユース ケースは完全なユース ケースではないため、完全にするためにはサブ ユース ケースと一緒に使用する必要があります。
• インクルード関係は、ユース ケース図では矢印付きの点線(線にマーク<<include>>) によって表され、矢印はベース ユース ケースからサブ ユース ケースを指します。

拡張する：

• extend (拡張された関係)、ベース ユース ケースの拡張。ベース ユース ケースは完全なユース ケースであり、サブ ユース ケースの参加がなくても、完全な機能を完了できます。
• extend の基本ユース ケースには拡張ポイントがあり、拡張ポイントがアクティブ化された場合にのみ、サブユース ケースが実行されます。
• 拡張関係は、ユース ケース図では矢印付きの点線 (線 上にマーク<<extend>>) によって表され、矢印はサブ ユース ケースからベース ユース ケースを指します。

サブユースケースとベースユースケースの関係は次のとおりです。

(汎化関係) 子ユースケースは、親ユースケースの構造、動作、関係をすべて継承します。つまり、ベース ユース ケースが使用されている場所はすべて、サブ ユース ケースで置き換えることができます。

（汎化関係）ユースケース図では白抜きの矢印で表されており、矢印の方向はサブユースケースからベースユースケースへ向かう方向となっている。

4) アイコン

(2) 静的図: クラス図、オブジェクト図、パッケージ図

1) クラス図

①定義：クラス図（クラス図）は、システムに関与するすべてのクラスとクラスとクラス間の関係を記述します。

②クラス図の基本構成：

• class (クラス名、プロパティおよびメソッド);
• クラスとクラス間の関係 (依存関係、関連、一般化、実装)。

2) オブジェクト図

①定義:オブジェクト図はクラス図のインスタンスであり、クラス図とほぼ同じ識別子を使用しますが、以下の凡例に示すように、両者には特定の違いがあります。

②凡例：

(3) 動作図: 状態図、アクティビティ図

1) 状態図

①定義：状態図（状態図）は、システムに関わるオブジェクトのすべての状態と、状態と状態の間を遷移するイベントを記述します。

② 状態図の基本構成：

• 状態(角丸長方形);
• 状態の開始と終了。
• 状態間の遷移のイベント。
• メモ（時々あります）。

③凡例：

2) アクティビティ図

①定義：アクティビティ図（アクティビティ図）は、ユースケースの機能要件を満たすために実行すべきアクティビティとアクティビティ間の制約関係を記述したものです。

②アクティビティ図の基本構成：

• アクティビティ (シンボルは状態とは異なることに注意してください)。
• アクティビティの開始点と終了点 (複数の終了点がある場合もあります)。
• アクティビティは矢印で結ばれています。
• 判定（エッジボックスがある場合もあります）。
• 同期バー (水平および垂直の両方でアクティビティの分岐または合流を示します)。
• スイムレーン (アクティビティのさまざまな責任を表す)。

③凡例：

(4) インタラクション図：シーケンス図、コラボレーション図

1) シーケンス図

①定義：シーケンス図はオブジェクト間の動的な協力関係を示します。。

②シーケンス図の基本構成：

• 物体;
• ライフライン (オブジェクトの真下にある点線で、一定期間にわたるオブジェクトの存在を示します)。
• 細い長方形のバー (オブジェクトがアクティブになっていることを示し、オブジェクトが何らかのアクションを実行していることを示します)。
• インタラクティブメッセージ (シーケンスがあり、メッセージは実際には受信オブジェクトの操作メソッドです)。
• 注釈 (利用可能な場合もあります)。
• コラボレーション図に変換できます。

③凡例：

2) 連携図

①定義：コラボレーション図（コールバレーション図）はシーケンス図と同じ機能を持ち、動的なコラボレーションを反映します。

②連携図の基本構成：

• 物体;
• 実線 (オブジェクト間の接続線。矢印がないことに注意してください)。
• インタラクティブメッセージ (シーケンスがあり、メッセージは実際には受信オブジェクトの操作メソッドです)。
• 注釈 (利用可能な場合もあります)。
• シーケンス図に変換できます。

③凡例：

(5) 実装図：構造図、展開図

1) 部品図

①定義：コードコンポーネントの物理構造とコンポーネント間の依存関係を記述します。

②コンポーネント図の基本構成：コンポーネント。

③凡例：

2) 展開図

①定義：システム内のハードウェアの物理アーキテクチャ。

②展開図の基本構成：

• 3D 立方体はコンポーネントを表します。
• ノード名は立方体の上にあります。

③凡例：

データフロー図とデータディクショナリ

1. データ フロー図のコンポーネント

データ フロー図の基本的なグラフィック要素には、データ フロー、処理、データ ストレージ、外部エンティティ (データ ソースまたはシンク) が含まれます。その中で、データ フロー、処理、およびデータ ストレージは、ソフトウェア システム内でデータ処理モデルを構築するために使用されます。外部エンティティは、システムの外部に存在するオブジェクトを表し、ユーザーがシステム データのソースと宛先を理解するのに役立ちます。DFD の基本的なグラフィック要素を次の図に示します。

**(1) データ フロー: **固定コンポーネントを持つデータのセットで構成され、データの流れを示します。DFD では、データ フローのフローには次のタイプがあります。

1) あるプロセスから別のプロセスへの流れ。

２）処理からデータ保存（書き込み）までの流れ。

３）データの保存から処理（読み込み）までの流れ。

4) 外部エンティティから処理 (入力) までの流れ。

5) 処理から外部エンティティ(出力)までの流れ。

DFD の各データ フローは、明確に定義された名前で表されます。データ ストアとの間で送受信されるデータ フローに名前を付ける必要がない場合を除き、各データ フローには、データ フローの意味を反映する適切な名前が必要です。DFD で記述されるのはデータ フローであり、制御フローではないことに注意してください。データ ストリームは、具体的なデータ属性 (データ構造とも呼ばれます) または他のデータ ストリームで構成されます。複合データフローは、データフロー図を読みやすくするために、高レベルのデータフロー図で類似のデータフローを結合するために使用される、他のデータフローで構成されるデータフローです。

**(2) 処理: **入力データ ストリームと出力データ ストリームの間の変換について説明します。つまり、入力データ ストリームが処理された後、出力データ ストリームになります。各プロセスには名前と番号が付いています。この番号は、プロセスが階層 DFD のどのレベルのどのマップに位置するかを反映することができ、また、それがどのプロセスから分解されたサブプロセスであるかを確認することもできます。処理を記述するためのデシジョンツリー、デシジョンテーブル、構造化言語があります。処理には複数の入力データ ストリームと複数の出力データ ストリームを含めることができますが、少なくとも 1 つの入力データ ストリームと 1 つの出力データ ストリームが必要です。

**(3) データストレージ: **データを保存するために使用されます。通常、プロセスに流入するデータ ストリームは処理後に消滅しますが、そのデータの一部 (またはすべて) は、他のプロセスまたは外部エンティティに流れる出力データ ストリームに処理される場合があります。さらに、ソフトウェア システムでは、後で使用するために特定の情報を保存する必要があることが多く、このときにデータ ストレージを使用できます。例えば、試験事務処理システムにおいては、登録時に生成された受験者名簿を登録処理中に継続的に補充する必要があり、合格者数の集計や受験者通知の際にも受験者名簿の関連情報を利用する必要がある。したがって、候補者名簿は、関連する候補者情報を保持するデータ ストアとして存在できます。**各データストアには明確に定義された名前識別子があります。** データ ストレージに流入するデータ フローが存在し、データの書き込み操作を示すこともあります。また、データ ストレージから流出するデータ フローが存在し、データの読み取り操作が存在することもあります。双方向矢印のデータ フローデータの変更を示す、データ ストレージを指すために使用することもできます。

ここで説明しておくべきことは、DFD におけるデータの保存は、実際の実装ではファイル システムまたはデータベース システムによって実現できるということです。データを保存するための記憶媒体には、ディスク、テープ、またはその他の記憶媒体を使用できます。

**(4) 外部エンティティ (データ ソースまたはシンク): ** ソフトウェア システムの外部に存在する個人または組織を指し、システムが必要とするデータの発信元 (ソース) とデータの宛先を示します。システム（宿泊施設）によって生成されます。たとえば、試験事務処理システムの場合、受験者はシステムに登録フォーム（入力データフロー）を提供するため、受験者は試験事務処理システムのソース（ストリーム）となり、試験センターはシンクとなります。システムのために。多くのシステムでは、特定のソースと特定のシンクが同じ人物または組織である場合があり、このとき、DFD ではそれらを同じシンボルで表すことができます。受験者はシステムに登録フォームを提供し、システムは受験者に受験チケットを送信するため、テスト管理システムでは、受験者はソースとシンクの両方になります。ソースとシンクは同じグラフィック シンボルで表され、データ フローがシンボルから流れる場合はソースであることを意味し、データ フローがシンボルに流れる場合はシンクであることを意味し、両方の場合はシンクであることを意味します。ソースとシンクの両方。

2 番目に、データ フロー図の階層化

原理的には、十分な大きさの紙であれば、ソフトウェア システムの解析モデルを 1 枚の紙に描くことができます。ただし、複雑なソフトウェア システムには、数百のプロセスやデータ フロー、あるいはそれ以上が含まれる場合があります。それらを 1 つの図に描くと、非常に複雑になり、読みにくく、理解しにくくなります。したがって、現時点では、通常、階層型データ フロー図は、もう少し複雑な実際的な問題を明確にモデル化するために使用されます。

階層型データ フロー グラフの最上位層には、ソフトウェア システム全体を表す 1 つの処理のみが存在するグラフが 1 つだけあり、この処理はソフトウェア システムと外部世界との間のデータ フローを記述しており、これを最上位層と呼びますグラフ。最上位グラフの処理（つまりシステム）を分解したグラフを0層グラフと呼び、グラフは1つだけ存在します。

階層化されたデータフローグラフの一番下のグラフをボトムグラフと呼びますが、このグラフではすべての処理が分解されなくなります。階層データフロー グラフ内の他のグラフは中間層と呼ばれ、少なくとも 1 つのプロセス (場合によってはすべてのプロセス) がサブグラフに分解されます。階層データ フロー図のセット全体において、サブグラフに分解されなくなった処理は、基本処理と呼ばれます。

3. データフロー図の事例分析

事例1：店舗業務管理システム

(1) 店舗経営管理システムのトップレベルのデータフロー図は次のとおりです。

上記のデータ フロー図は、ターゲット システムによって実現される機能を反映した高レベルのシステム ロジック モデルにすぎません。

(2) 管理システムのデータ フロー図の描画手順は次のとおりです。

• まずシステムの入力と出力を決定します。
• ストアのビジネスに応じて、最も重要なビジネスの処理フローを反映するトップレベルのデータ フロー図を作成します。
• 分析後、店舗業務処理の主な機能には、販売、購買、会計が含まれるはずです。主要なデータ フローの入力ソース ポイントと出力宛先ポイントは、顧客とサプライヤーです。
• そして入力側から店舗業務のワークフローに沿ってデータフローが流れる各処理フレームを描画し、徐々に出力側まで描画して第0層のデータフロー図を取得します。

(3) レイヤ 0 とレイヤ 1 のデータフロー図をそれぞれ手順に従って描画します。具体的なグラフィックスは次のとおりです。

• レイヤ 0 のデータ フロー図を次の図に示します。

• 第0層のデータフロー図の各処理項目を絞り込むと、営業、調達、会計の3大機能を含む第1層のデータフロー図が得られます。具体的なデータ フロー図は次のとおりです。

事例2：在学状況管理システム

(1) 学生ステータス管理システムのトップレベルのデータフロー図は次のとおりです。

(2) 管理システムのデータ フロー図の描画手順は次のとおりです。

• まずシステムの入力と出力を決定します。
• 学生ステータス管理システムの業務に応じて、最も重要な業務の処理フローを反映する最上位のデータ フロー図を作成します。
• 分析の結果、学生ステータス管理システムの主な機能に応じて、登録、成績管理、資格管理、報酬管理の 4 つの主要な機能があるはずです。メインのデータフローの入力元と出力先は生徒と教師です。
• 次に、入力側から、学業状況管理システムの関連業務のワークフローに従って、データフローが流れる各処理フレームを描画し、徐々に出力側に描画して、 0番目のデータフロー図を取得します。層。

(3) 手順に従ってレイヤー0のデータフロー図を描画します。具体的なグラフィックスは次のとおりです。

• レイヤ 0 のデータ フロー図を次の図に示します。

ケース 3: 大規模企業のデータセンター

ユーザーのデータへのアクセスを集中管理および制御し、多数の接続要件をサポートするために、大企業のデータセンターはデータ管理ミドルウェアを構築したいと考えています。その主な機能は次のとおりです。

(1) データ管理者はミドルウェアを通じてユーザー管理、運用管理、権限管理を行うことができます。ユーザー管理は、ユーザー テーブルに保存されるユーザー情報 (ユーザー名、パスワード) を維持します。操作管理は、データ エンティティの標準操作と、操作テーブルに保存されるバックエンド データベース情報を維持します。権限管理は、権限テーブルを維持します。 、ユーザーが実行できる操作情報が保存されます。

(2) ミドルウェアは、フロントエンド アプリケーションから提供されたユーザー情報を検証します。検証に失敗した場合は、不正なユーザー情報を返します。検証に合格した場合、ミドルウェアはフロントエンド アプリケーションが操作リクエストを送信するのを待ちます。

(3) フロントエンド アプリケーションが操作リクエストを送信した後、ミドルウェアはまずリクエストの形式をチェックします。形式が正しくない場合は形式エラー情報を返し、形式が正しい場合は権限検証（要求された操作を実行する権限がユーザーにあるかどうかを確認）を実行し、ユーザーに操作を実行する権限がない場合は不十分な形式を返します。許可情報、それ以外の場合は接続管理を実行します。

(4) 接続管理は、対応するバックエンド データベースに接続し、操作を送信します。接続管理では、まずアイドル状態のデータベース接続があるかどうかを確認し、ない場合は新しい接続を作成し、存在する場合はその接続を再利用します。

(5) バックエンドデータベースは演算を実行してその結果をミドルウェアに送信し、ミドルウェアは受け取った演算結果を処理してフロントエンドアプリケーションに返します。

次に、構造化手法を使用してシステムを分析および設計し、次の図に示すように、トップレベルのデータ フロー図と0 レベルのデータ フロー図を取得します。

次の質問に答えてください。

1. E1、E2、E3 はどの 3 つのエンティティを指しますか? E1: フロントエンド アプリケーション、E2: データ管理層、E3: バックエンド データベース。
2. D1、D2、D3 はどの 3 つのデータストアを参照しますか? D1: ユーザーテーブル、D2: 操作テーブル、D3: 権限テーブル。
3. 処理Pとは何を指しますか? また、データ ストリームの開始点、終了点、データ ストリーム名など、0 層のデータ フロー グラフで欠落している 2 つのデータ ストリームを指摘します。処理 p はデータ管理ミドルウェアを表します。0 層のデータ フロー図で失われた 2 つのデータを 4 と 5 に示します。
4. 失われたデータ ストリーム 1 の開始点、終了点、および名前は何ですか? →始点をP、終点をE、名前は処理後の演算結果です。
5. 失われたデータ ストリームの開始点、終了点、および名前は何ですか 2. →始点はE3、終点はP、名前は演算結果です。

4. データ辞書の事例分析

事例1：在学状況管理システム

学生ステータス管理システムのレイヤー 0 データ フロー図を以下に示します。

**質問: **上記のレイヤー 0 データ フロー図に従って、学生ステータス管理システムの 5 つのエントリを書き出してください。

答え：

項目 1: データ フロー

項目 2: データ要素

項目 3: データストレージ

項目 4: データ処理

項目 5: 外部アイテム