Wondershare EdrawMind
マインドマップギャラリー 情報システム分析とデザインマインドマップ
- 4
情報システム分析とデザインマインドマップ
システム分析・設計の概要、システム要件調査、ユースケース、ドメインモデルなど、情報システムの分析・設計に関するマインドマップです。
2023-11-14 10:01:51 に編集されました
- おすすめ
- アウトライン
情報システムの分析と設計
chap01 システム解析と設計の概要
導入
これは、情報システムの開発に役立つ一連の仕様、ガイダンスです。
1.1 ソフトウェア開発とシステム分析・設計
コンピュータアプリケーション
コンピューティングデバイス上で特定の機能セットを実行するコンピュータソフトウェアプログラム
中程度の適用範囲
「アプリケーション」（アプリ）とも呼ばれます。
情報システム
ビジネス タスクを完了するために必要な情報を収集、処理、保存、提供する、相互に関連するコンポーネントのセット
「アプリケーション」よりも広い範囲
ソフトウェア、データベース、および関連する手動プロセスが含まれます
システム分析
人々が情報システムが何を達成すべきかを理解し、特定できるようにする活動
システムデザイン
要件を解決するシステムを定義し、詳細に説明できるようにするアクティビティ
システム分析は設計図を描くことに相当し、システム設計は詳細な計画に相当します。
1.2 システム開発ライフサイクル
プロジェクト
始まりと終わりがあり、特定の結果を生み出す計画されたタスク
情報システム開発用
システム分析およびシステム設計のツールと技術の知識が必要です
SDLC（System Development Life Cycle）、つまりシステム開発のライフサイクル
システム開発ライフサイクルは、情報システムの構築、立ち上げ、保守に必要なすべてのアクティビティを含むプロセス全体を特定します。
すべてのアクティビティには、システム分析、システム設計、プログラミング、テスト、システム保守が含まれます。
6つのコアプロセス
問題やニーズを特定し、承認を得る
プロジェクトの計画と監視
問題やニーズの詳細を発見して理解する
問題を解決したりニーズを満たすシステムコンポーネントを設計する
システムコンポーネントの構築、テスト、統合
システムテストを完了してからソリューションを展開する
情報システム開発プロセス
システムのテストを完了し、ソリューションを展開することにより、特定の情報システムを開発するための実践的なアプローチ (別名: 方法論)
例えば
統合プロセス (UP)
エクストリーム プログラミング (XP)
反復的な増分ソフトウェア開発プロセス スクラム
現在、ほとんどのプロセス/メソッドはアジャイルで反復的な開発を使用しています。
アジャイル開発アジャイル開発
開発中に新しい要件を予測する柔軟性を重視した情報システム開発プロセス
変化に素早く対応します。
ユーザーもチームメンバーも新しいシステムの問題や複雑さを完全には理解していないため、プロジェクトの計画と実行では予期せぬ問題を考慮する必要があります。
反復開発反復開発
複数の反復を通じてシステムを徐々に「成長」させるシステム開発のアプローチ
システムの小さな部分 (ミニプロジェクト) を完成させ、その後、改良と追加のプロセスを繰り返し、完了するまで改良と追加を繰り返します。
アドバンテージ
1. システムの一部を迅速に導入できる
2. プロジェクト内の困難な問題をできるだけ早く見つけることができるように、最初に開発する小さな部分を取り出します。
プロジェクトを反復するための 6 つの中心的なプロセス
円の面積は、このプロセスの対応する反復のワークロードを表します。
各反復では、異なる焦点を当てた複数のプロセスが実行されます。
1.5 RMO取引システムを例として開発プロセスを紹介
1.5.1 準備
問題を特定し、システムの目標を文書化する (コアプロセス 1)
予備調査
結果をシステム ビジョン ドキュメント (SVD) に変換します。
プロジェクト開始の承認を得る（コアプロセス1）
経営陣を含む主要な関係者と会う
経営幹部を含む主要な関係者と会い、意思決定を行い、計画と予算を承認する
SVD（システムビジョンドキュメント）
システムビジョン文書は、会社に利益をもたらす機能とシステムに含まれる機能を特定するために使用されます。
2つのステップで行う
最初のメリットステートメントを作成する
詳細な収益とコストの見積もりを追加する
通常は 3 つの部分で構成されます
問題の説明
システム機能
ビジネス上のメリット
1.5.2 初日の活動
コアプロセス 2: プロジェクトの計画
必要な主要コンポーネント (機能領域) を特定する
システムをサブシステムまたはコンポーネントに分割する
サブシステムはシステム全体の一部です
反復を定義し、各機能領域を反復に割り当てます。
単一の反復を計画する
反復に必要なタスクを決定する
特定されたタスクは、作業分解構造 (WBS) と呼ばれるリストにまとめられ、整理されます。
例
WBS（ワークブレイクストラクチャー）の内容
分解根拠（名称）
分解の基礎は次の 4 つのコアプロセスに依存します。
所要時間
執行順序
所要時間や実行順序を計測することで、その後の運用ネットワークの構築やクリティカルパス（PERT）の計算に役立てることができます。
クリティカルパスはネットワーク全体で最も長いパスであり、他のパス上の処理はある程度の柔軟性を持って実行される必要があります。
これらのタスクを日付ごとに整理して保管します
WBSをスケジュールに変換する
個別の繰り返しを計画する利点は、スケジュールが非公式であり、予期せぬ状況に合わせて調整できることです。
作業順序の下書きを作成する
下書き作業指示の利点
1. チームワークの整理を助ける
2. 反復が計画どおりに進んでいるかどうかの尺度を提供します。
3. このスケジュールでプロジェクトに時間がかかる場合、プロジェクト リーダーは、プログラミングにより多くの時間とリソースが必要になる可能性があることを認識し、プロジェクトのこの部分を支援するためにリソースを早期に整理できます。
必要なリソース (人) を特定し、対応するタスクを実行する人員を手配します。
チームメンバーと責任を特定する
1.5.3 2日目の活動
要件を理解するために、事前の事実調査タスクを実行します。 (コアプロセス3)
第2章で詳しく解説します
ユースケースの予備リストとユースケース図を作成します。 (コアプロセス3)
使用事例
ユースケースは、単一のユーザーによってトリガーされたビジネス イベントと、そのイベントに対するシステムの応答を記録します。
ユースケースとは、システムの使用例または状況を指します。
例: 購入エージェントはこのシステムを「使用」して「サプライヤーに問い合わせ」ます。
ユースケースは通常、要件/機能に対応する動詞です
ユースケースリストの例
ユースケース図の例
予備的なクラスリストとクラス図を作成します。 (コアプロセス3)
オブジェクトクラス
オブジェクト クラス識別システムは、現実世界のそれらのものを理解し、追跡する必要があります。
オブジェクトクラスはシステムに情報を保存する必要がある
クラスリストの例
クラス図の例
これは予備的なクラス図であるため、プロパティ (静的機能) のみが存在します。
デザインクラス図には属性データ型やクラスメソッドなどが含まれます。
上の図は、統一モデリング言語 UML を使用して開発されています。
1.5.4 3日目の活動
詳細を知るために綿密な事実調査を実施します。 (コアプロセス3)
各ユースケースの詳細なワークフローを理解し、文書化します。 (コアプロセス3)
ユースケースの説明とワークフロー図を作成する
ユースケースの詳細を文書化する 2 つの方法は次のとおりです
ワークフロー図を開発するには、UML の図であるアクティビティ図を使用する必要があります。
ワークフロー図の例
図の楕円はタスクを表し、ひし形は意思決定ポイントを表し、矢印はシーケンス フローを表し、中心線を横切る矢印はユーザーとシステム間の対話を表します。
画面とレポートのユーザー エクスペリエンスを定義します。 (コアプロセス3および4)
画面レイアウトを定義する
1.5.5 4日目の活動
データベースの構造（スキーマ）を設計します。 (コアプロセス4)
テーブルデザイン
キーワードとインデックス識別子
プロパティタイプ
参照整合性
データベーススキーマの例
システムの上位構造を設計します。 (コアプロセス4)
全体的な建築設計
予備設計のクラス図を定義する
予備設計クラス図の例
デザイン クラスには、クラスに必要なクラス レベルの変数が含まれており、各クラスの重要なメソッドのメソッド名も表示されます。設計クラス図の最後の要素は矢印であり、どのクラスが他のどのクラスのメソッドにアクセスできるかを示します。
サブシステムアーキテクチャの設計
1.5.6 5日目の活動
詳細設計へ進む（CP4）
プログラミングと個別テストの実行 (CP5)
設計とプログラミングは、全体を設計してからプログラミングするのではなく、部分を設計してプログラミングし、次に部分を設計して、再度プログラミングすることです。
1.5.7 6日目の活動
完全なシステムテスト (CP6)
システム全体の機能テスト
ユーザー受け入れテスト
部分システムの展開の可能性 (CP6)
1.5.8 最初の反復のレビュー
1.6 以降のコンテンツの紹介
1.6.1 第 1 部 システム開発の概要
第一章
1.6.2 パート 2 システム分析アクティビティ
第 2 章、第 3 章、第 4 章、および第 5 章
1.6.3 第 3 部 システム設計活動
第 6 章と第 7 章
1.6.4 パート 4 プロジェクトとプロジェクト管理
第8章と第9章
1.6.5 パート 5 高度な概念と展開の概念
第10章、11章、12章
chap02 システム要件調査
2.1 はじめに
この章では、SDLC プロセスの範囲と詳細を拡大して、より広範囲の概念、ツール、およびテクニックをカバーします。この章ではシステム分析アクティビティ (リストされている 3 番目のコア プロセス) に焦点を当てていますが、次の章では、これらのシステム分析アクティビティ中に開発されたモデルについて詳しく説明します。後続の章では、他のコア SDLC プロセスについて詳しく説明します。
2.2RMO向けCSMS（総合営業・マーケティングシステム）
2.2.1RMO の既存の情報システムとアーキテクチャ
アーキテクチャは 2 つのタイプに分けられます
テクノロジー アーキテクチャ テクノロジー アーキテクチャ
テクノロジ アーキテクチャは、組織で使用されるコンピューティング ハードウェア、ネットワーク ハードウェアとトポロジ、およびシステム ソフトウェア (オペレーティング システムやデータベース管理システムなど) のセットを記述します。
アプリケーション アーキテクチャ アプリケーション アーキテクチャ
アプリケーション アーキテクチャは、組織の情報システムを実装するためにソフトウェア リソースがどのように編成および構造化されるかを記述します。ソフトウェアをモジュールとサブシステムに編成することについて説明します。これには、サポート技術 (プログラミング言語や開発環境など)、アーキテクチャ的アプローチ (サービス指向アーキテクチャなど)、およびユーザー インターフェイス技術 (モバイル コンピューティング ディスプレイ、タッチ スクリーンなど) が含まれます。テクノロジー、音声認識など）。
2.1.2 新しい CSMS
新しい統合販売およびマーケティング システムには 4 つのサブシステムが含まれます
販売サブシステム
注文実装サブシステム
顧客アカウントサブシステム
マーケティングサブシステム
2.3 システム分析活動
主要な部分は 5 つあります
2.3.1 詳細情報の収集
インタビュー、アンケート、文書作成、ビジネスプロセスの観察、サプライヤーの調査、意見や提案
2.3.2 要件の定義
機能要件と非機能要件のモデリング
2.3.3 要件の優先順位付け
2.3.4 ユーザー インターフェイスのダイアログ ボックスの開発
ユーザーとシステム間の対話プロセス
2.3.5 ユーザーとともにニーズを評価する
ユーザーエンゲージメント、フィードバック、変化への適応
2.4 需要とは何か
システム要件とは、新しいシステムが実行またはサポートする必要があるすべてのアクティビティと、新しいシステムが満たさなければならない制約です。
システム要件は次のように分かれています。
機能要件
機能要件とは、システムが実行しなければならないアクティビティ (たとえば、システムが適用される業務) です。
ユーザーによる実行が必要
非機能要件
非機能要件は、システムが実行またはサポートする必要があるアクティビティを超えた特性です。
パフォーマンス指標、制約（開発ツール、データ形式など）など
FURPS を使用して要件を単純に分割できます
機能的な機能
ユーザビリティの可用性
信頼性
パフォーマンス
安全
その他、制約条件など
非機能要件
2.5 モデルとモデリング
モデル
モデルは、構築されるシステムのいくつかの側面を表現したものです。
モデルの種類
テキストモデル
報告書、書類
グラフィカルモデル
回路図
数学的モデル
式
モデリング言語
多くのグラフィカル モデルの開発は、UML (未定義モデリング言語) を通じて実装されます。
UML は、非営利団体である Object Management Group によって定義された標準モデル構造とシンボルのセットです。
2.6 利害関係者
利害関係者とは、システムの導入の成功に関心を持つすべての人々です。
ステークホルダーの分類
内部関係者
内部利害関係者とは、システムと対話する組織内の人々、またはその運用や成功に重大な関心を持つ組織内の人々です。
外部の利害関係者
外部利害関係者とは、組織の管理や影響力が及ばない人々のことです。
運営上の関係者
運用上の利害関係者は、仕事や生活の中でシステムと頻繁にやり取りする人々です。
たとえば、簿記は会計システムや請求システムと対話し、工場労働者は生産スケジュール システムと対話し、顧客はインターネット店頭と対話し、患者は医療 Web サイト、Facebook ページ、または Twitter ニュース フィードと対話します。
利害関係者の管理
経営上の利害関係者とは、システムと直接対話しないが、システムによって生成される情報を使用するか、システムの運用と成功に金銭的またはその他の重大な利益を有する人々です。
例: 組織の上級管理職、取締役会、規制当局、税務当局。
2 種類の重要なステークホルダー
クライアント: 経済的支援を提供する人
システム技術サポート担当者
2.7 情報収集技術
情報収集技術としては、
2.7.1 ユーザーおよびその他の関係者とのインタビューを実施する
システムアナリストが必要です
詳しい質問を用意する
質問の主題
ビジネスプロセスとは何ですか?
ビジネスプロセスの仕組み
どのような情報が必要か
質問の種類
未解決の質問
終了した質問
質問対象: 旧システムまたは新システム
個々のユーザーまたはユーザーのグループに会う
質問に対する答えを得て話し合う
回答を記録する
今後の面接に役立つ情報をフォローアップする
2.7.2 アンケートの配布と回収
3種類の質問
終了した質問
フォーマットの問題を見てください
未解決の質問
2.7.3 入力、出力、処理の確認
入力、出力、プロセスの 2 つのソースがあります
組織内の業務記録とプロセスの説明
組織の外部から – 業界全体の専門組織やその他の企業
既存の処理ドキュメントを確認する
2.7.4 ビジネスプロセスの観察と記録
これはビジネスの機能を理解するのに役立ちます
2.7.5 サプライヤーのソリューションを調査する
3 つの利点と 1 つの危険
1. これらのソリューションを検討すると、ユーザーはビジネス機能をより適切に実行する方法についてよりよく考えることができます。
2. 一部のソリューションはすでに一流であり、調査を行わずにトレンドに追いつくのは困難です。
3. ソリューションを購入することは、ソリューションを調査するよりもリスクが少なく、安価です
危険: システムのニーズをすべて調査せずに、急いでソリューションを購入すること
2.7.6 アクティブなユーザーのコメントを収集する
2.8 アクティビティ図を使用してワークフローを記録する
ワークフロー
ワークフローは、ビジネス トランザクションや顧客のリクエストを完全に処理する一連の処理ステップです。
アクティビティ図
アクティビティ図は、さまざまなユーザー (またはシステム) アクティビティ、各アクティビティを実行する人々、およびそれらのアクティビティの一連の流れを記述します。
記号と説明
楕円は、ワークフロー内のさまざまなアクティビティを表します。接続矢印はアクティビティ間の順序を示します。黒丸はワークフローの開始と終了を示します。ダイヤモンドは、プロセスがどちらかのパスに従うかの決定点です。太い実線は、パスを複数の同時パスに分割したり、同時パスを再結合したりできる同期バーです。スイム レーンのタイトルは、アクティビティを実行するエージェントを表します。通常、ワークフロー内にはワークフロー プロセスのさまざまなステップを実行するさまざまなエージェント (つまり人) が存在するため、スイム レーン シンボルはワークフロー アクティビティをグループに分割し、どのエージェントがどのアクティビティを実行するかを示します。
Chapter03 使用例
3.1 はじめに
第 4 章と第 5 章と同様に、この章では、さまざまなモデルを作成して機能要件を文書化する手法を紹介します。
ユースケースは、通常はユーザーの要求に応じてシステムが実行するアクティビティです。
ユースケースで機能要件を定義する
アナリストはシステムを一連のユースケースに分解します (機能分解)
ユースケースは通常、動詞または動名詞にちなんで名付けられます
3.2 ユースケースとユーザーの目標
ユースケースを定義する手法の 1 つは、ユーザー目標手法です。これは、新しいシステムまたは更新されたシステムを使用するための目標をユーザーに説明するよう求めます。
8つのステップに分かれています
新しいシステムの潜在的なユーザーをすべて特定する
機能上の役割（輸送、マーケティング、販売など）に基づいて潜在的なユーザーを分類する
潜在的なユーザーを組織レベル (運営、管理、役員など) ごとにさらに分類します。
ユーザーのタイプごとに、ユーザーを訪問し、新しいシステムを使用する際の具体的な目標 (現在の目標と付加価値をもたらす革新的な機能) のリストを見つけます。
ユーザーのタイプごとに整理されたユースケースの予備リストを作成する
類似したユースケース名を持つコピーを見つけて不一致を解決する
異なるタイプのユーザーが同じユースケースを必要とする場所を判断する
完成したリストを各タイプのユーザーおよび関係者とともに確認します。
通常、機能要件のあるイベントのみが考慮されます。
ユーザーターゲティング手法はシンプルだが一般的に使用されている
3.3 ユースケースとイベントの分解
イベント分解テクノロジーは、ユースケースを特定するための最も包括的なテクノロジーです。
イベント分解テクノロジーは、まず情報システムの応答を引き起こすすべてのビジネス イベントを特定し、各イベントがユースケースにつながります。ビジネス イベントから始めると、アナリストが適切な詳細レベルで各ユース ケースを定義できるようになります。
ユースケースの適切な詳細レベルを決定するために使用されるのは、Essential Business Process (EBP) です。
EBP は、ビジネス イベントに対応し、測定可能なビジネス価値を追加し、システムとそのデータを安定した一貫した状態にするために 1 か所で 1 人の担当者が実行するタスクです。
ビジネス イベントが発生すると、各 EBP がそれに応答します
3.3.1 イベント分解技術
イベント
イベントは特定の時間と場所で発生し、記述可能であり、システムによって記憶される必要があります。
3.3.2 イベントの種類
外部イベント
外部イベントは、システムの外部で発生するイベントであり、通常は外部エージェントまたはアクターによって開始されます。
外部エージェント (またはアクター) は、システムにデータを提供または受信する個人または組織単位です。
例えば
ユーザーの注文などのさまざまなビジネスプロセス。
外部イベントは通常、ユーザー (アクター) の要求に応答するために使用され、人間とコンピューターの対話環境で発生します。
時限イベント/一時的な時間
ある時点に到達した結果として発生するイベント。
例えば
統計レポート等を定期的に送付します。
システム内で一時的なイベントが発生する
ステータスイベント
ステータス イベントは、処理要件をトリガーするイベントがシステム内で発生したときに発生します。
ステータス変化時に発生
一般に、これらは非機能要件であるため、考慮されることはあまりありません。
3.3.3 イベントの定義
イベント/前提条件/応答
アナリストは一連のイベントを検討し、実際にシステムに影響を与えるイベントを特定する必要があります。
一連の出来事
特定の外部エンティティまたはアクターに発生した一連のイベントを追跡するのに役立ちます
テクノロジー依存イベントとシステム制御
アナリストは、システムにとって重要ではあるが、ユーザーやトランザクションには直接関係のないイベントに関心を持つ場合があります。これらのイベントには通常、設計の選択やシステム制御が含まれます。分析者は分析中、これらのイベントを一時的に無視する必要があります。
システム制御は、システムの整合性を保護するために設計されたチェックまたはセキュリティ手順です。
データのバックアップやログインなど
分析フェーズでは、理想的な技術的仮定を使用します。
完璧なテクノロジー仮説では、システムが完璧な条件下で応答する必要がある場合にのみイベントが発生する必要があると述べています (例: デバイスは決して故障せず、処理能力とストレージ能力は無制限で、システムを操作する人々は完全に正直で決して間違いを犯さない)。分析プロセスに含まれます。
3.3.4 イベント分解技術の使用
1. システムの応答を必要とするシステム環境内の外部イベントを考慮します。
2. 外部イベントごとに、システムに必要な使用例を特定して名前を付けます。
3. チェックリストを使用して、システムの応答が必要な時間イベントを検討します。
4. 時間イベントごとに、システムに必要なユースケースを特定して名前を付け、そのユースケースをトリガーする時点を確立します。
5. 特にデバイスまたは内部状態の変化がユースケースを引き起こすリアルタイム システムの場合、システムが応答する可能性のある状態イベントを考慮します。
6. ステータス イベントごとに、システムに必要なユース ケースを特定して名前を付け、ステータスの変更を定義します。
7. イベントとユースケースを定義した後、それらが完全な技術的前提を必要とするかどうかを確認します。ログイン、ログアウト、パスワード変更、データベースのバックアップまたはリカバリなどのシステム制御に関連するイベントはシステム制御として配置されるため、含めないでください。
3.4 ユースケースとCRUD
ユースケースを検証し改良するためのもう 1 つの重要なテクノロジーは CRUD テクノロジーです。
CRUDとは
作成する
読んで読んで
アップデート、アップデート
削除、削除
これらはデータベース管理に関連する操作です
CRUD 手法は、クロスチェックとしてユーザー ターゲティング手法と併用すると最も役立ちます。ユース ケースを識別する方法として直接使用するのではなく、ユース ケースがビジネス プロセスをうまく追跡できなくなる可能性があります。
不足しているユースケース タイプがないかどうかを確認できます
CRUDテクノロジーのステップ
1. 新しいシステムに関係するすべてのデータ エンティティまたはドメイン クラスを特定します。
2. データの種類 (データ エンティティまたはドメイン クラス) ごとに、新しいインスタンスの作成、既存のインスタンスの更新、インスタンス値の読み取りまたはレポート、およびインスタンスの削除 (アーカイブ) の使用例を特定していることを確認します。
3. 必要なユースケースが無視された場合は、新しいユースケースを追加し、関係者を特定します。
4. 統合アプリケーションの場合は、どのアプリケーションがデータの追加と維持を担当し、どのシステムがデータのみを使用するかを明確にしてください。
3.6 ユースケース図
ユースケース図は、ユースケースとそのユーザーとの関係をグラフィカルに表示するために使用される UML モデルです。
3.6.1 ユースケース、アクター、シンボル
ほとんどのユースケースでは、これまでユーザーと呼んでいたシステムを使用する人々が暗黙的に存在します。 UML では、この人物をアクターと呼びます。アクターはオートメーションの境界の外側にあることがよくあります
ユースケース図では、人間のシンボルがアクターを表し、楕円形がユースケースを表し、長方形の境界線がオートメーション境界を表し、ユースケースとアクターの間の接続は、どのアクターがどのユースケースに参加しているかを表します。
例
ユース ケースとアクターの間に関係があるだけでなく、ユース ケース間にも関係がある場合があります。
これはユースケース間の依存関係であり、2 つの形式があります。 破線の矢印と << >> を使用して示します
<<含める>>
これは、あるユース ケースを別のユース ケースで使用することを指す使用関係として理解できます。矢印で示されたユース ケースは、使用されるユース ケース (依存) です。この関係では、あるユース ケースを別のユース ケースで使用する必要があります。
<<拡張>>
この関係は、あるユース ケースが別のユース ケースを使用する可能性があることを示しています。この関係には、拡張ポイントと呼ばれるものがあります。たとえば、図書館管理システムでは、本の返却に罰金 (タイムアウトなど) が発生する可能性があります。これは拡張された関係です。
2 つの関係は、両方ともユース ケース間の関係であり、どちらも 1 つのユース ケースで別のユース ケースを使用することを意味し、2 つの違いは、include は別の UC が確実に使用されることを意味し、extended は拡張を判断する必要があることです。使用するかどうかを決める前のポイント
chap04 ドメインモデル
4.1 はじめに
中心となる概念: システムのユーザー問題領域にあるもの
4.2 問題領域にあるもの
問題領域とは、新しいシステムに含まれるユーザー ビジネスの特定の領域を指します。
ドメイン クラスまたはエンティティは、エンド ユーザーがスタジオで作業する必要があるもので、システムの問題ドメインでは「モノ」と呼ばれることがよくあります。
例えば
製品、注文、顧客
4.2.1 問題領域の定義方法 1 - ブレーンストーミング法
1. ユーザーと一連のユースケースを特定します。
2. ユーザーとブレインストーミングを行って、ユースケースの実行に関係するもの、つまりシステムが情報を取得する必要があるものを特定します。
3. モノのタイプ (カテゴリ) を使用して、潜在的なモノについて系統的に質問します。たとえば、次のような質問です。具体的なモノに関する情報は保存していますか?関係する場所はありますか?誰の役割を覚えておく必要がありますか?
4. 引き続きさまざまなユーザーや関係者と協力してブレインストーミング リストを拡大します。
5. 結果を結合し、重複を削除し、初期リストを作成します。
4.2.2 問題領域で物事を定義する方法 2 - 名詞テクノロジー
ユーザーが言及したすべての名詞をリストします。イベント、ユースケース、またはアクターを説明するために使用される名詞は、潜在的なものです。
ステップ
1. ユースケース、アクター、およびシステムに関するその他の情報 (入力と出力を含む) を使用して、すべての名詞を特定します。
2. 既存のシステム、現在の手順、および現在のレポートまたはフォームからのその他の情報を使用して、必要な情報の項目またはカテゴリを追加します。これらのアイテムの中には、追加のものである場合もあれば、すでに特定しているものに関するより具体的な情報 (属性と呼ばれる) である場合もあります。リストを改良し、調査したい仮説や質問を記録します。
3. この名詞のリストが作成されると、それを調整する必要があります。
名詞を含めるべきかどうかを判断するには、各名詞について次の質問をしてください。
それはシステムが認識する必要がある固有のものですか?
それは私が開発しているシステムの範囲内ですか?
システムは上記の項目のうち複数を記憶する必要がありますか?
各名詞について次の質問をして、除外する必要があるかどうかを判断します。
それは本当に私が特定した他のものの同義語ですか?
それは本当に、私が特定した他の情報に基づいた単なるシステム出力なのでしょうか?
それは本当に、私が特定した他の情報を記録する単なる入力なのでしょうか?
各名詞について次の質問をして、それを研究する必要があるかどうかを判断してください。
私が特定した他のものに関する特定の情報 (プロパティ) である可能性はありますか?
仮定が変わった場合、それが必要になる可能性がありますか?
4. 識別されたすべての名詞のマスター リストを作成し、各名詞を含めるか、除外するか、またはさらに研究するかを指定します。
5. ユーザー、関係者、チームメンバーと一緒にリストを確認し、問題領域内の項目のリストを絞り込みます。
例
4.2.3 物の性質
ほとんどのシステムは、属性と呼ばれるトランザクションに関する特定の情報を保存します。
何かを一意に識別する属性は、識別子またはキーワード (キー/コード) と呼ばれます。
複合属性は、住所、氏名など、複数の関連する属性で構成されます。
4.2.4 物事間の関係
関連とは、特定の物事の間に自然に生じる関係を指します。
UML では、物事間の関係には大まかに 4 種類あります。
協会
世代の一般化
依存関係依存関係
埋め込む
関連する詳細
名前があります
方向があり、矢印が指すものは他のものを見ることができません（つまり、矢印が指すものに依存して、指すものは他のものに変化しますが、その逆は効果がありません）
たとえば、A->B は、B に依存する A と呼ばれます。
関連とは多重性、つまり、あるものと別のものの間の量的な関係です。
例
アソシエーション間にはカーディナリティの制限があります
関連する要素
アソシエーションはいくつかの異なるタイプのもので構成されており、これらのものの数がアソシエーションのアリティとなります。
顧客と注文、二項関係
類似したものの間の関連付け、1 つの要素
3 つ以上の異なる種類のものが関連しており、複数の
4.3 エンティティと連絡先の図
これはデータベースモデリング用のモデルです
長方形はエンティティを表し、長方形を接続する線はエンティティ間の接続を表します。
象徴的な表現
1 つだけ存在することを表すために、垂直線のみが切り捨てられます。
縦線を切り落として丸で囲み、0または1を表します。
十字線の付いた円は0以上を示します
垂直線が切り取られ、二股に分かれた線は 1 つ以上を表します。
番号に対応する方向は符号なしから符号付きへ
エンティティの属性では、1行目に主コード(識別子)が配置され、主コードであることを示すためにPKがマークされます。
例
1 人の顧客は 0 から複数の注文に対応します。1 つの注文は 1 人の顧客に対応します。
4.4 ドメインモデルのクラス図
問題のクラスはドメイン クラスと呼ばれます
UML では、システムのオブジェクト クラスを表示するためにクラス図が使用されます。
ドメインモデルのクラス図
ユーザーの問題領域にあるものを表示するために使用されます
クラス図の設計
デザイン用
象徴的な表現
クラス図では、四角形はクラスを表し、四角形を結ぶ直線はクラス間の関係を表します。
長方形には 2 つの部分 (ドメイン モデル クラス図、デザイン クラス図はクラス名、属性、メソッドの 3 つの部分で構成されます) があり、上部がクラス名、下部がクラスの属性です。
クラス名と属性名にはキャメルケースの名前が使用され、クラス名の最初の文字は大文字で、属性名の最初の文字は小文字になります。
4.4.1 ドメインモデルのクラス図の表記
多重度記号
エンティティ関係図の多重度と同様に、クラス インスタンス間の関係の数を表します。
例
ここでの多重度は、エンティティ関係図のマッピング カーディナリティに似ています。
特定のドメインクラス図のアプリケーション
これは、学生のコースを選択するためのドメイン モデル クラス図です。コースには 0 個から複数のセクションを含めることができますが、1 つのセクションは 1 つのコースにのみ所属でき、セクションは多対多の関係を持つことができます。ゼロ; 学生とコースの間には、点線でマークされた関連付けクラスがあり、成績の属性が付いています。
4.4.2 オブジェクトクラスに関するより複雑な問題
ドメイン クラスには 3 種類の関係があります
協会
一般化/専門化の生成
一般化/専門化の関係の基礎は、人々が類似点と相違点に基づいて物事を分類することです。
一般化/特殊化の関係は、これらのものをより一般的なものからより具体的なものへと構造化または順序付けるために使用されます。
階層内の各クラスには、その上位にスーパークラスと呼ばれる、より一般的なクラスがある場合があります。
クラスの下に、サブクラスと呼ばれる、より特殊なクラスがある場合があります。
継承により、サブクラスはスーパークラスの特性を共有できます。
三角矢印を使用してスーパークラスを指します
例
抽象クラスにラベルを付けるには斜体を使用します
抽象クラスはインスタンス化できず、継承のみが可能です。
インスタンス オブジェクトを持つことができるクラスである具象クラスもあります。
スーパークラスは具体的な場合と抽象的な場合があります
全パート
グローバル/パート関係は、クラスと、このクラスに含まれる他のクラスとの間の関係を表現するために使用されます。
重合
集約関係では、コンポーネントは独立して存在できます。
中空のダイヤモンドを使用して表現します
組み合わせ
結合関係では、各部分が一度関連すると独立して存在することはできません。
ソリッドダイヤモンドを使用して表現します
Chapter05 要件モデルの拡張
5.2 ユースケースの説明
ユースケースの説明では、各ユースケースの詳細が説明されています。
簡単な使用例の説明
単一のシナリオと少ない例外に適しています
例
完全に開発されたユースケースの説明
より複雑なユースケースの場合は、完全に拡張されたユースケースの説明が必要です。
標準テンプレート
ユースケース名
ユースケースのシナリオ
トリガーイベント
簡単な説明
参加者
それに関連するその他のユースケースとその関連付け方法
ステークホルダー
前提条件
前提条件によって、ユース ケースの開始時のシステムの状態が決定されます。これには、すでに存在している必要があるオブジェクト、利用可能でなければならない情報、さらにはユース ケースの開始前のアクターの条件も含まれます。
その後の条件
事後条件は、ユースケースが完了したときに何が真でなければならないかを決定します。最も重要なのは、ユースケースがどのような新しいオブジェクトを作成または更新するか、およびオブジェクトをどのように関連付ける必要があるかを示すことです。
活動の流れ
参加者（ユーザー）とシステムを含めた活動の流れ
異常事態
各ユース ケースのアクティビティ フローは、ユース ケースを呼び出すアクターに応じて大きく異なる場合があります。これらのアクティビティ フローはシナリオと呼ばれ、ユース ケース インスタンスとも呼ばれます。
5.3 ユースケースのアクティビティ図
ユースケースを記録する 1 つの方法は、アクティビティ図を使用することです。第 2 章でアクティビティ図を使用してワークフローを構築する方法を学習しました。ここではアクティビティ図を使用して、ユースケースのアクティビティ フローを記録します。
例
このアクティビティ図は、顧客登録ユースケース登録のアクティビティ フローを示しています。
5.4 システムシーケンス図 SSD
システム シーケンス図は、オートメーション システムに出入りする情報の流れを説明するために使用されます。
人間のシンボルを使用してユースケースのアクターを表し、長方形の境界線を使用して自動化の境界を表します
四角形にはシステム (コロン付き) のマークが付けられ、自動化システムを示します。
参加者とシステムの下にはライフラインと呼ばれる点線があり、参加者とシステムのライフサイクルを表しており、時間はトップダウン方向に流れます。
参加者とシステムのライフラインの間でメッセージの送受信が行われます。
メッセージの送信は、参加者からシステムへの方向を示す実線で表されます。
受信したメッセージは、システムから参加者への方向を示す破線で表されます。
メッセージの完全な記号表現
(*)[真偽条件] 戻り値:=メッセージ名(パラメータリスト)
* はループを示します
[]内はtrueとfalseの条件を表し、内側がtrueの場合はメッセージが送信され、それ以外の場合は送信されません。
メッセージ名は送信されたメッセージの説明です
パラメータリストは渡す情報です
さらに、代替フレームワークがいくつかあります
ループ変更
複数のメッセージがループで送受信される場合は、代替フレームワークを使用した方がよい場合があります。
別のフレームは、長方形のフレームを使用してループする部分を選択し、左上隅のすべてのアイテムのループを表現します。
変更を選択
select の代替フレームは else と一緒に使用されます。選択領域を選択するには、点線を使用して、送信されるメッセージの最後の部分に else のラベルを付けます。
5.4.2 SSDの開発
1. 入力メッセージを確認する
2. 外部からシステムに渡される情報をメッセージシンボルで表現する
3. 入力メッセージにループや true/false 条件などの特定の条件を追加します。
4. 返信メッセージを確認して追加する
5.5 ステートマシン図 ステートマシン図
オブジェクトの状態は、オブジェクトの存続期間中に、特定の条件が満たされたとき、特定のアクションが実行されたとき、または何らかのイベントが待機されたときに発生する条件です。
状態遷移は、ある状態から別の状態に移行するオブジェクトのアクティビティです。
状態遷移関数
変換名(パラメータ、...) [判定条件]/動作説明
action-expression は、遷移が完了してオブジェクトがターゲット状態に到達する前に発生する必要があるプロセスを表します。
条件は遷移の修飾子またはテストであり、遷移がトリガーされる前に満たされる必要がある単なる true/false 条件です。
5.5.1 複合状態と同時状態
同時に複数の状態にあることは、同時実行性または同時状態と呼ばれます。
アクティビティ図と同様の同時パスを使用して表現されるパスは、相互接続された状態遷移の順序付けされたセットです。
他の上位レベルの状態の中に状態を入れ子にします。これらの上位レベルの状態は複合状態と呼ばれます。
複合状態は、下位レベルの状態にネストされた上位レベルの状態によって表されます。
例
プリンタの電源が入っているとき (複合状態)、用紙トレイ部分と印刷部分という 2 つの同時パスがあり、オン ボタンを押すと電源がオンになり、オフ ボタンを押すと 2 つの部分が独立します。押すとオフになります。制限はありません。
5.5.2 ステートマシン図を作成するためのルール
クラス図を表示し、状態を必要とする可能性のあるクラスを選択します
グループ内で選択したクラスごとに、判断できるすべてのステータス条件をリストします。
オブジェクトが特定された状態から離れる原因となる遷移を特定することにより、ステート マシン ダイアグラム フラグメントの構築を開始します。
これらの状態遷移の組み合わせを正しい順序で並べます。
これらのパスを確認し、独立した同時パスを探します。
他のコンバージョンを探す
適切なメッセージ イベント、ガード条件、アクション式を使用して各遷移を拡張します。
各ステートマシン図の確認とテスト
5.6 需要モデルの統合
さまざまな需要モデル間の関係
ユースケース図
ユースケースの説明
アクティビティ図
SSD
ドメインモデルのクラス図
ステートマシン図
この関係は次の図で説明されます。
矢印は依存項目から依存項目への方向を指します。
実線は主な依存関係を表し、点線は副次的な依存関係を表し、一部の矢印は双方向であり、相互影響を示します。
chap06 デザインの基本とデザイン活動
6.1 はじめに
分析フェーズでは主にシステムの機能 (要件など) について議論しますが、設計フェーズでは主にシステムがこれらの要件をどのように達成するかについて議論します。
システム設計の入力と出力はシステムの入力と出力ではありません。システム設計の入力はシステム分析の結果、つまり要件と関連モデルですが、システム設計の出力はより詳細なソリューションです。
6.2 設計要素
6.2.1 システム設計とは何ですか?
システム設計は、構築の青写真として最終ソリューションのコンポーネントを定義、編成、構築することを目的とした、システム分析と実装の間の橋渡しプロセスです。
6.2.2 主要コンポーネントと設計レベル
メインコンポーネント
環境デザイン
システムを接続するネットワーク、ハードウェアなどについて説明します。
アプリケーション設計
コンピュータープログラム
ユーザーインターフェイスの設計
定義された入出力用の画面、レポート、コントロール
データベース設計
データベース構造
システムインターフェース設計
他のシステムとの通信について説明します
セキュリティと制御の設計
2つのレベル
建築デザイン
システム全体の構造の大まかな設計であるソリューション全体の枠組みと形を明確にする
全体設計、概念設計とも呼ばれます。
詳細設計
特定のプログラミングの詳細が含まれます
例
ユースケースごとの設計
データベース設計
ユーザーインターフェースとシステムインターフェースのデザイン
セキュリティと制御の設計
6.3 システム設計の入出力
システム分析で得られた分析モデルやドキュメントなどの情報を、解決システムを表すモデルに変換
解析モデル
クラス図
ユースケース図 UCD
システムシーケンス図 SSD
ユースケースの説明
ステートマシン図
アクティビティ図
デザインモデル
パッケージマップ
ノードとロケーションのグラフ
クラス図の設計
フローチャート
データベーススキーマ
ユーザーとシステムのインターフェース
システムセキュリティ管理
連携図
6.4 設計活動
設計活動は、上記の 6 つのコンポーネントの設計です。各設計活動には、対応する重要な課題があります。
環境デザイン
ソフトウェアが実行される環境とさまざまなオプションをすべて詳しく説明しましたか?
アプリケーションのアーキテクチャとソフトウェアの設計
ソフトウェアのすべての要素と、各ユースケースがどのように実行されるかを詳しく説明しましたか?
ユーザーインターフェイスのデザイン
このシステムが組織内外の他のすべてのシステムとどのように通信するかを詳しく説明しましたか?
システムインターフェース設計
ユーザーがすべてのタスク [ユースケース] を実行するためにシステムと対話する方法を詳しく説明しましたか?
データベース設計
すべてのスキーマ要素を含むすべての情報ストレージ要件を指定しましたか?
セキュリティと制御の設計
システムとデータの安全性と保護を確保するために必要なすべての要素について詳しく説明しましたか?
6.4.1 設計環境
環境とは、ソフトウェア アプリケーションをサポートするために必要なすべてのテクノロジです
サーバー、デスクトップコンピュータ
モバイルデバイス、オペレーティングシステム
コミュニケーション能力、インプット・アウトプット能力
第 2 章ではこれを技術アーキテクチャと呼びました
6.4.2 アプリケーションのアーキテクチャとソフトウェアの設計
システムをサブシステムに分割する
ソフトウェアアーキテクチャの定義（アーキテクチャ設計）
MVC 3層アーキテクチャなど
各ユースケースの詳細な設計
クラス図の設計
フローチャート
ステートマシン図
6.4.3 ユーザーインターフェースの設計
ダイアログの設計は要件から始まります
デザインにより、画面レイアウト、ルックアンドフィール、ナビゲーション、ユーザーエクスペリエンスが追加されます
デバイスごとに異なるインターフェイスを設計する
6.4.4 システムインターフェースの設計
情報システムは他の多くの内部および外部システムと対話します。
システム インターフェイスはさまざまな方法で他のシステムに接続します
6.4.5 設計データベース
ドメイン モデル クラス図 (ERD) から始める
データベース構造の選択
設計アーキテクチャ (分散など)
データベーススキーマの設計
テーブル、属性列
設計参照の整合性制約
6.4.6 セキュリティとシステム制御の設計
目的は、インターネットとワイヤレスの世界で重要な組織の資産を保護することです
ユーザーインターフェースコントロール
アプリケーション制御
データベース制御
ネットワーク制御
6.5 環境を設計する方法
オンプレミスで設計する
オンプレミス ソフトウェア システムには 2 種類あります
スタンドアロン ソフトウェア システム
ネットワークなしでデバイスから実行
Webベースの社内システム
ハードウェア展開: LAN
クライアントサーバーアーキテクチャ
デスクトップ アプリケーション システム (クライアント/サーバー)
ブラウザベースのアプリケーション システム (ブラウザ サーバー)
ハイパーテキスト マークアップ言語をページとして使用する
トランスポートプロトコルとしてTCP/IPプロトコルを使用する
3 層クライアント/サーバー アーキテクチャ
ソフトウェアを設計する効果的な方法は、ユーザー インターフェイス層とビジネス ロジック層を分離し、ビジネス ロジック層とデータ アクセス層を分離することです。このプログラムの設計方法は 3 層アーキテクチャと呼ばれます。基本的な考え方は、ソフトウェアを 3 つの層に分割することです。
ビュー層: ユーザー入力を受け取り、それをフォーマットされた出力に処理する役割を果たします。
論理層/ドメイン層 ドメイン層: ビジネスまたは処理プロセスを実装するルールと手順を担当します。
データ層: 通常、1 つ以上のデータベースに存在する保存データの管理を担当します。
複数の層を 1 台のコンピューター上で実行することも、各層を別個のコンピューターで実行することもできます。その場合、層の機能を分散するか、冗長コンピューター実装間で負荷分散を実装することで、複雑な層を 2 つまたは 3 つの層に展開できます。
もう 1 つの設計アイデアは MVC、つまり Model-View-Controller です。
外部展開の設計
重要な質問には次のものが含まれます
インターネット展開の構成
データ保護は、ハイパーテキスト転送プロトコル セキュリティ (HTTPS) を使用して実装されます。HTTPS プロトコルによって提供される Web ページは、HTTP よりも安全な暗号化された形式で送信されます。
多層サーバー構造、負荷分散、およびコンテンツ配信ネットワーク (CDN) を使用してパフォーマンスを向上させます。
アプリケーションサーバーとデータベースサーバーを含む多層サーバー構造
リクエストは負荷分散コンピュータを通じてさまざまなデータセンター サーバーに送信されます。
一部の静的な写真やビデオにアクセスする場合、独立した CDN を使用してそれらを送信できます。
インターネット導入のためのホスティング オプション
会場レンタル
顧客がサーバー コンピューターを配置するための安全なデータ センターを提供する利点は、物理的で安全かつ複雑なデータ センターのコストがかからないことです。
マネージドサービス
オペレーティング システム、ネットワーク サーバー、データベース サーバーなどの管理を含む追加サービスを提供します。利点は、サーバー システムやシステム ソフトウェアを管理するために従業員を雇う必要がないことです。
仮想サーバー
固定サイズの仮想サーバーをレンタル可能
クラウドコンピューティング
お客様は、必要かつ使用するコンピューティング容量のみを購入する必要があり、コンピューティング容量が増加すると、クラウドが自動的に追加の容量を提供するため、不必要な容量を購入する必要がなく、コストを節約できます。
すべての代替案には、特定レベルのシステム可用性を保証するための企業とホスティング会社間の契約の一部であるサービス レベル アグリーメント (サービス レベル アグリーメント) があります。
インターネット用に導入された顧客デバイスの多様性
コンピューター
中型タブレット端末
小型モバイルデバイス
リモート環境および分散環境向けの設計
仮想プライベート ネットワーク (VPN) を介したリモート展開
VPN は、インターネットなどの公衆ネットワーク上に構築されるネットワークです。プライベートグループに安全で接続可能なネットワークを提供します
chap07 ユーザーインターフェースとシステムインターフェースの設計
7.2 ユーザーインターフェースとシステムインターフェース
ユーザー インターフェイスには、ユーザーの直接の介入を必要とする入力と出力が含まれています。
システムインターフェイスには最小限の手動入力と出力が必要です
7.3 ユーザーインターフェースを理解する
ユーザー インターフェイスには 3 つのコンポーネントがあります
物理的な意味: オフィスの机と椅子、ランプ、キーボード、マウス、タッチ スクリーン
認識される意味: 色、形、テクスチャ、フォント、ウィンドウ、メニュー、ボタン
概念的な意味: 顧客、参加者、注文、輸送、フィードバック
ユーザー インターフェイスの設計観点はユーザー中心であり、人間とコンピューターの間のインタラクション (人間とコンピューターのインタラクション) を強調しています。
ヒューマンコンピュータインタラクションは、コンピュータシステムとのユーザーインタラクションの効率と有効性、人間指向の入出力技術、およびユーザーインターフェイスの心理的側面を研究する分野です。
ユーザー中心設計の3つの基本原則
ユーザーとその仕事に早い段階で焦点を当てる
システムを評価して使いやすさを確保する
反復開発を使用する
人間とコンピュータの相互作用のメタファー
メタファーは、ユーザー インターフェイスの機能とユーザーにとって馴染みのある物理的エンティティの間の類似点です。
メタファーは、次の状況でユーザー インターフェイスのデザインで広く使用されます。
直接操作
ディスプレイ上の物理オブジェクトまたはそれらを表すオブジェクトを直接操作します。
例: ユーザーがフォルダーをごみ箱にドラッグします。
デスクトップのメタファー
ビジュアル表示をさまざまなエリアに整理し、中央に一連のツール アイコンで囲まれた大きな空のワークスペースを配置します。
例: Windows デスクトップ
文書の比喩
ページやテーブルなどのデータを表示する
例：取扱説明書など
会話の比喩
ユーザーとコンピュータは、テキスト、音声、またはその他のツールを使用してコミュニケーションまたは対話を行うことでタスクを完了します。
例: コマンドウィンドウ
最初の 3 つはユーザーと対話するオブジェクトを強調し、会話のメタファーはユーザーとコンピューターの間で発生するコミュニケーションを強調します。
7.4 ユーザーインターフェイスの設計概念
7.4.1 即時性と可視性
指標とは、そのパフォーマンスを反映するコントロールの外観を指します。
可視性とは、コントロールが表示されることを意味します
7.4.2 一貫性
7.4.3 ショートカット
7.4.4 フィードバック
7.4.5 ダイアログを完了する
7.4.6 エラー処理
7.4.7 アクションを元に戻す
7.4.8 短期記憶への負担を軽減する
7.5 分析からユーザーインターフェース設計まで
7.5.1 ユースケースとメニュー階層
メニューは、関連する多数のユースケースや会話をユーザー インターフェイスで整理する方法です。
設計者は、ユースケースの数に基づいてメニュー階層を推定する必要があります。
メニュー レベルには通常 5 ～ 10 のオプションが含まれます
7.5.2 ダイアログとストーリーボード
ユーザーが必要とする会話を録音する必要がある
ストーリーボード: 会話中にこの一連の画面スケッチを表示します。
7.6 ユーザーインターフェースの設計
7.6.1 フォームとテーブルの設計ガイドライン
インターフェースのレイアウトとフォーマット
一貫性、ラベルとタイトル、分布と順序、フォントと色
データ入力
テキストボックス、リストボックス、コンボボックス、ラジオボタン、チェックボックス
指導・支援制御
最小化、最大化、閉じる、スクロールバー、サイズ変更
7.6.2 ブラウザインターフェースの追加ガイドライン
一貫性
カスケード スタイル シート (CSS) - Web サイト設計者が、常に同じに見えるページの部分と、タスクや対象者に応じて異なる部分を指定できる Web ページのコーディング標準。
パフォーマンスに関する考慮事項
ネットワーク接続、転送される情報量、転送される情報の種類に影響されます。
写真、ビデオ、サウンド
互換性の問題が発生します
特別利用者（障害者）
支援技術 – 障害のある人の特別なニーズにユーザー インターフェイスを適応させるソフトウェア (テキスト読み上げツールや音声認識ツールなど)
7.6.3 モバイルデバイスインターフェースに関する追加ガイドライン
モバイルデバイスのユーザーインターフェイス設計における課題
小さな画面、キーパッドとタッチ スクリーン、限られたネットワーク容量、アプリケーション設計ガイドラインとツールキット
7.7 システムインターフェースの決定
システム インターフェイスは、ユーザーの介入をまったくまたはほとんど必要としない入力と出力として広く定義されます。
以下のカテゴリーに分かれています
他のシステムからの入出力
XML (Extensible Markup Language) は、システム間の電子データ交換と通信に使用できます。
XML は、HTML と比較してカスタム データ構造の埋め込みを実装します。
高度に自動化された入出力
外部データベースからの入出力
7.8 設計システムへの入力
7.8.1 自動入力デバイス
データ入力の主な目的は、エラーのないデータをシステムに提供または更新することです。最も重要なことは、エラーをできるだけ回避することです。
自動入力デバイスを使用する
人の介入を可能な限り避ける
入力情報がスプレッドシートから取得できる場合は、データを再入力せずにスプレッドシートを使用します
データの検証と修正
7.8.2 システム入力の詳細を定義する
7.9 設計システムの出力
報告書、明細書、返送書類の設計
レポートの種類
詳細レポート: ビジネス プロセスに関する詳細情報が含まれます。
概要レポート: このタイプのレポートは、段階的なアクティビティを要約するために使用されます。
異常レポート：トランザクションや操作結果が異常な場合に生成されます。
経営陣のレポート: 全体的な健全性と業務の評価
内部出力は、組織または部門の内部使用のために生成されます。前述のレポートは、組織の外部メンバーが使用するために生成されます。たとえば、注文確認情報、月次決算書などです。社外向けに作成される公式のビジネス文書であり、より高い品質が求められるため
返却ドキュメントと呼ばれる外部出力のタイプがあり、ユーザーに提供される出力は、後でシステムへの入力として使用できる部分で構成されます。たとえば、返却される支払い明細を含む請求書などです。チェック。
電子明細書
グラフィックスとマルチメディアのプレゼンテーション
Chapter08 システム開発手法
8.2 システム開発ライフサイクル
8.2.1 システム開発ライフサイクルの従来の予測方法
予測手法は、組織開発プロジェクトを事前に計画し、計画に従って新しい情報システムを開発できる手法です。
要件: プロジェクトが事前に計画でき、情報システムが計画に従って開発でき、要件がよく理解され、技術的リスクが低いことが前提となります。
ウォーターフォールモデル
プロジェクトでは、ライフ サイクルの 6 つのフェーズが 1 つのフェーズから次のフェーズに進行し、各フェーズは連続しています。
従来のウォーターフォール モデルでは、SDLC のさまざまなステージ間に重複や反復がありません。
スケールの比較的右側のモデルは、改良されたウォーターフォール モデルです。
改良されたウォーターフォール モデルでも、予測された開発フェーズの順序は保持されていますが、これらのフェーズは重複し、影響し合い、相互に依存しています。
柔軟性が向上しますが、予測計画と順次フェーズが前提となります。
8.2.2 システム開発ライフサイクルへの適応的なアプローチ
適応モデルは、要件 (要件) が明確でなく、多くの場合、複数の反復が必要な場合に開発に使用できます。
プロジェクトは、開発プロセス中に需要が不確実であり、技術的なリスクが高いため、より柔軟でニーズの変化に適応する必要があります。
スパイラルモデル
スケールの右端から比較的遠い
SDLC をスパイラルで表現し、中心から外側に向かって繰り返し拡張し、プロジェクトが完了します。
ステージごとに複数回
反復モデル
第 1 章の開発方法と同様に、表の行は開発アクティビティ、列は反復を表します。
各反復には複数の段階が含まれており、各段階は一度に完了するのではなく、後続の反復で継続的に改善されます。
適応的アプローチに関する追加の概念
段階的な開発
基本的なコンセプトは、システムは少しずつ構築され、有機的に成長するというものです。
プロジェクト中、システムは段階的に実装され、部分的に展開されます。
利点は、ユーザーがシステムの一部をすぐに入手できるため、できるだけ早くビジネスを開始できることです。
歩く骸骨
完全なシステム構造を構築し、基本的な機能のみを提供するための初期のアプローチ
まず、新しいシステムの完全な実装プロセスの「骨格」を前から後ろまで提供し、その後の反復を使用して骨格を埋めます。
プロジェクトでは、極端な選択ではないことがよくあります
8.3 サポートフェーズ
予測アプローチ SDLC には、このようなサポートフェーズが含まれます
適応型アプローチでは、サポート段階を完全な自己完結型プロジェクトとして扱います。
サポート段階では 3 つの主なアクティビティが発生します。
メンテナンス体制
体制を強化する
サポートユーザー
8.4 方法、モデル、ツール、および技術
システム開発手法
メソッドの適用範囲が最も広い
方法論には、プロジェクトのあらゆる側面のモデル化など、アクティビティとタスクを完了するための一連のテクニックが含まれます。
モデル
モデルは現実世界の特定の側面を抽象的に表現したもので、関連する部分のみに焦点を当てることで複雑な概念を理解できるようになります。
各モデルは異なる情報を強調します
私たちはすでにこれらのモデルのいくつかに触れています: ER 図、ユースケース図、クラス図、シーケンス図
道具
ソフトウェアサポート
テクノロジー
学習を通じて獲得した
8.5 ソフトウェア構築とモデリングの 2 つの方法
8.5.1 構造化されたアプローチ
構造化手法はプロセスに焦点を当て、データ フローを中心にしています。システムがデータ フローと対話するプロセスの集合であることを前提としています。
構造化手法は、SDLC 予測手法と同じ従来の手法です。
構造化分析
データフロー図を使用したモデリング
ER図も使用されます
構造化されたデザイン
構造図を使用したプログラムの設計
低結合性と高凝集性が必要
低結合とは、異なるモジュールが他のモジュールから可能な限り独立していることを意味し、1 つのモジュールを変更しても他のモジュールの動作に影響を与えません。
高い凝集性とは、各モジュールが明確なタスクを実装していることを意味します
構造化プログラミング
開始、終了、および 3 つの構造 (シーケンス、選択、サイクル) が含まれます。
トップダウンプログラミング/モジュール設計
8.5.2 オブジェクト指向のアプローチ
オブジェクト指向のアプローチでは、システムを、特定の相互作用を達成するために連携して動作するオブジェクトの集合として見なします。
オブジェクトとは、システム内でメッセージに応答するものです
オブジェクト指向分析
新しいシステムでのユースケースとオブジェクト (クラス) のセットを特定して定義するプロセス
オブジェクト指向設計
人やデバイスと通信するために必要なすべてのタイプのオブジェクトを定義し、それらがタスクを完了するためにどのように対話するかを示します。
クラス図やユースケース図などのモデルを使用する
オブジェクト指向プログラミング
実際のクラスとクラスの各オブジェクトの役割を定義するステートメントを作成します。
シーケンス図やデザインクラス図などのモデルを使用する
8.6 アジャイル開発
未知の急速に変化する環境で行われる開発活動
8.6.1 アジャイル開発の理論と価値
核心理論
計画に従うことよりも変化への対応に重点を置く
プロセスやツールではなく、個人と対話を重視する
包括的なドキュメントよりも実用的なソフトウェアを重視する
契約交渉よりもクライアントとのコラボレーションに重点を置く
アジャイル プロジェクトの概念を説明する: カオス
それはカオスと秩序です。最初の 2 つの中心理論、つまりグループの価値観に対する個人の価値観の優位性がカオスの原因であり、このカオスは柔軟性を高めることで処理できるようになります。予測できない開発プロセスでは混乱が避けられませんが、開発者は混乱を受け入れる必要がありますが、プロジェクトに秩序と構造を追加するために有益な他の方法やテクニックを使用する必要がある場合もあります。
簡単に言うと、全体の秩序を確保しながら、多少の混乱は許容するということです。
Chapter09 プロジェクト計画とプロジェクト管理
これらは 6 つの主要なセクションのうちの最初の 2 つです: 問題を特定して承認を得る、プロジェクトを計画して監視する
9.2 プロジェクト管理の原則
9.2.1 プロジェクト管理の要件
統計によると、成功したプロジェクトの 3 分の 1 未満
一部のプロジェクトが失敗する理由
主な理由: 上級管理職の関与と管理スキルの欠如
ユーザーグループへの参加の欠如
9.2.2 プロジェクトマネージャーの役割
プロジェクト管理は、事前に決定されたスケジュールと予算に従って計画された結果を達成するために他の人を組織し、指示するプロセスであり、プロジェクトを計画し、それを監視および制御するプロセスとしても定義できます。
プロジェクトマネージャーの内部責任
プロジェクトのスケジュールを作成する
チームメンバーを採用し、トレーニングする
チームメンバー間で作業を調整する
プロジェクトのリスクを評価する
プロジェクトのマイルストーンを監視および制御する
人材とリソースを管理する
プロジェクトマネージャーの対外的責任
プロジェクトのステータスと進捗状況を報告する
顧客やその他の関係者と直接連携する
リソースのニーズを判断し、リソースを入手する
広報活動のコーディネート
プロジェクトマネージャーは多様な人々と協力します
クライアント: システムに資金を提供する人
監視委員会: プロジェクトを監督するクライアントおよびその他の上級マネージャーで構成されます。
ユーザー: システムを直接使用してタスクを完了する人
プロジェクトマネージャーには社内と社外の二重の機能がある
9.2.3 プロジェクト運営と式典（式典）
プロジェクトの形式的な程度、つまり儀式もプロジェクト管理に影響を与えます
小規模なプロジェクトでは、ローエンドの儀式が行われることがよくあります
大規模で複雑なプロジェクトでは、質の高いセレモニーが行われることがよくあります。
従来の予測手法を使用する場合と適応型手法を使用する場合では、プロジェクトの儀式が異なります
アダプティブ プロジェクトの管理方法は、多くの場合、より形式的または非公式です。UP (統一プロセス) は非常に形式的で厳格な儀式が行われますが、反復手法はより非公式です。
9.2.4 プロジェクト管理知識体系
PMBOKは9つのモジュールで構成されています
プロジェクト規模の管理
プロジェクトの時間管理
プロジェクトのコスト管理
プロジェクトの品質管理
プロジェクト人事管理
プロジェクトコミュニケーション管理
プロジェクトのリスク管理
プロジェクト調達管理
プロジェクト統合管理
9.2.5 アジャイルなプロジェクト管理
アジャイルなプロジェクト管理
範囲はよく理解されていないが、制御する必要がある
いくつかのガイドラインを使用してビジネスの優先順位を決定する
アジャイルな時間管理
スケジュールは変更に柔軟に対応する必要があります
アジャイルなコスト管理
コストの見積もりはより困難であるため、コスト管理は予測アプローチほど重要ではありません。
アジャイルなリスク管理
プロジェクトのリスクの高い部分が最初に完了する
アジャイルな品質管理
各反復後に品質評価を実施する
9.3 主要プロセス 1: 問題を特定し、承認を得る
9.3.1 問題の特定
新しいシステムを開発する 3 つの主な目的
新たな開発機会への対応
市場シェアを占める
既存のビジネス上の問題を解決する
外部コマンドに応答する
法律、税金など
問題を定義する効果的な方法は、システム ビジョン ドキュメント (SVD) を作成することです。
3つのパーツが含まれています
問題の説明
問題と解決策は何ですか?
システム機能
新しいシステムにはどのような機能が搭載されますか?
ビジネス上のメリット
組織への利益（有形または無形）
9.3.2 プロジェクトの承認要因を定量化する
明確にする必要がある
推定完了時間
開発費の見積もり
ランニングコストの目安
前収入
費用便益分析
いくつかの概念
NPV (正味現在価値) 正味現在価値
特定の投資の利益と費用の現在価値
「現在の収益」を使用してコストを差し引くことによって計算されます（割引係数を使用）
コスト回収ポイント
この期間中、ドルの利益がドルのコストを相殺した
目に見えるメリット
お金で測れるメリットの部分
無形の利益
組織にとってのメリットはあるが、定量的に測定したり正確に見積もることはできない
サービスレベルの向上（金額では測れない方法で）
顧客満足度の向上 (金額では測定できない)
サバイバル - このように競争する必要があります
社内の専門知識を開発する必要がある (例: 新技術のパイロット プロジェクト)
費用便益分析手法
現在価値を推定値として使用する
システム寿命の計算
正味現在価値を毎年累積して回収期間と最終収益を計算します
例
回収期間は、累積正味現在価値の正負の転換点を整数部として使用し、小数部は（最後の負の値/合計差額）を使用して計算されます。
9.3.3 リスク評価と実現可能性分析
組織のリスクと存続可能性を判断する
技術的なリスクと実現可能性を評価する
リソースのリスクと実行可能性を評価する
スケジュールのリスクと実現可能性を判断する
9.3.4 承認に関して顧客と協力する
実行委員会の審査と承認
取締役会は非常に大規模なプロジェクトを審査し承認する必要がある
関係者は自分たちに何が期待されているかを理解する必要がある
IS 部門は人員配置とサポートに関して何をすべきかを知る必要がある
組織全体がこのプロジェクトとその重要性を認識する必要があります
9.4 コアプロセス 2: プロジェクトの計画と監視
9.4.1 プロジェクト環境の確立
ここでいうプロジェクト環境とは、先ほどの環境設計とは異なり、システムなどに必要な技術ではなく、作業環境やチーム内外のコミュニケーションのことを指します。
記録と通信 - 内部/外部
作業環境 – サポート/設備/ツール
PC またはワークステーション
個人開発ソフトウェアとツール
リソースライブラリ、通信ツールを備えたサーバー
オフィス、会議室、プリンター、その他の設備
サポート社員（チーム外）
プロセスと手順
レポートと文書
プログラミング
テスト
成果物
コードとバージョン管理
9.4.2 作業の進捗状況を調整する
プロジェクトの反復スケジュールを使用して、ユースケースを反復に割り当てます。
各反復で完了する必要があるタスクと作業の詳細なスケジュールをスケジュールします - 詳細な作業スケジュールを使用します
反復的な詳細な作業スケジュールを作成するための 3 つのステップ
作業分解構造WBSを作成する
労力の見積もりと依存関係の特定
ガットチャートを使用してスケジュールを作成する
作業分解構造には以下が含まれます
分解基準
所要時間
執行順序
WBS からの関連情報に基づいて時間を評価し、場合によってはクリティカル パスを使用して依存関係を見つけます。
ガント チャートは、アクティビティが棒で表示され、水平のタイムラインに表示される棒グラフです。
最初のタスクを除いて、すべてのタスクには先行タスクがあります。
明るい色の部分はクリティカル パスであり、全体の進行に影響するため、注意深く監視する必要があります。
9.4.3 スタッフとリソースの割り当て
5つのタスク
プロジェクトでリソース計画を作成する
特定の技術従業員を特定してリクエストする
特定のユーザー従業員を特定してリクエストする
チームをワークグループに編成する
初期トレーニングとチームビルディング演習を確立する
9.4.4 評価作業プロセス
回顧展
9.4.5 監視プロセスと修正
個人またはチームに仕事を割り当てる
収集状況
タスクは完了し、目標は達成されましたか?
異常を分析する
例外は重要ですか?
正しい行動を取る
第10章 オブジェクト指向設計: 設計原則
10.2 オブジェクト指向設計: 分析と実装の間の架け橋
10.3 オブジェクト指向アーキテクチャ設計（上位設計）
ソフトウェアシステムは大きく2種類に分けられます
シングルユーザー システム: リソースを共有せずにユーザーのデスクトップまたはサーバーで実行されます。
エンタープライズレベルのシステム: コンポーネントは複数の人または組織間で共有できます。
サーバー/クライアント システム
インターネットシステム（ブラウザ/サーバー）
システム アーキテクチャ設計に影響を与える 3 つの基本的な違い
州
クライアント/サーバーは状態ベースのシステムであり、クライアント/サーバー接続の存続期間は長くなります。
インターネット システムはステートレス システムであり、接続は長時間ではありません
クライアントの展開
画面やテーブルを直接表示
画面や表はブラウザ経由で表示されます
サーバーの導入
アプリケーションまたはクライアントがサーバーに直接接続する
クライアントはブラウザ経由でアプリケーション サーバーに間接的に接続します。
コンポーネント図とアーキテクチャ設計
システム全体のアーキテクチャとその中の論理コンポーネントを示し、システムがどのように実装されるかを示す設計図の一種
コンポーネント図は、ロジック、再利用性、移植性のためにシステムコンポーネントを識別します
コンポーネント図の基本要素は、API を備えたコンポーネント要素です。
API は外部からアクセスできるパブリック メソッドです。
コンポーネント図には 2 種類の API があります
入力ソケット（ソケット）
出力ポート（ポート）
例
事例：インターネットの2層アーキテクチャ設計（実際には3層にすることも可能）
ユーザーインターフェース層（ビュー層）
ドメイン層（論理層）
データベースアクセス層（データ層）
コンポーネント図を使用して表現する
10.4 オブジェクト指向詳細設計の基本原則
オブジェクト指向の詳細な設計手順
予備設計のクラス図を作成する
CRC カードを使用してクラスの責任とユースケースの協力を決定する
ユースケースごとに詳細なシーケンス図を作成します。最初に予備的なシーケンス図を作成し、次に多層シーケンス図を作成します。
メソッドの特性とナビゲーション情報を追加する
ソリューションをパッケージに分割します (パッケージ図)
10.5 設計クラスと設計クラス図
10.5.1 デザインシンボル
プロトタイプは、要素をその特性に基づいて分類する方法であり、<<>> で表されます。
デザインプロトタイプは4種類
エンティティクラス
問題ドメイン クラスの設計識別子。通常は永続的で、<<entity>> で表されます。
永続クラスとは、システムがシャットダウンされた後もデータを保持するクラスを指し、メソッドを実装すると、そのデータがデータベースまたはファイルに書き込まれます。
例
教育管理システムにおける学生と教師
コントロールクラス
<<controller>> で表される、ルータやスイッチと同様に、ビュー クラスとエンティティ クラスの間を調整する役割を果たすクラスです。
クラスを見る
ビュー クラスまたは境界クラスは、ユーザーに面した入力ボックスや Web ページと同様に、システムのオートメーション境界上にあり、<<境界>> で表されます。
データベースアクセスクラス
<<dataAccess>> で表される、データベースからデータを取得して返すクラスです。
各プロトタイプ クラスには異なるシンボルがあります
10.5.2 デザインクラス表現
デザインクラスで属性の形式を定義する
可視性
別のオブジェクトからプロパティに直接アクセスできるかどうかを示します (または -)。通常は public() ではなく private(-)
プロパティ名
小文字のキャメルケース
型式
クラス、文字列、整数、倍精度、日付
初期値
財産
中括弧内 ({key} など)
メソッドの形式（メソッドの特性）を定義する
メソッドの可視性
メソッド名
メソッドの戻り値の型
パラメータリスト
例
プロパティの名前と型の間にはコロンがあり、パラメータ リストとメソッドの戻り値の型の間には、初期値の前に等号があります。
抽象クラスを示すには斜体のクラス名を使用します
継承のみを許可し、インスタンス化を許可しないクラスは、通常、より高いレベルの抽象概念を表します。
10.5.3 予備設計クラス図の作成
属性の絞り込み
設計者は経験に基づいて属性タイプを決定します。ほとんどの場合、属性は非表示 (プライベート) です。
ナビゲーションの可視性
ナビゲーションの可視性とは、クラスが別のクラスに対して可視か不可視かを指し、あるオブジェクトが別のオブジェクトを表示および操作できることを示します。
矢印を使用して、示されている方向が表示されている側であることを示します
この例では、顧客は販売クラスを参照しているため、顧客には販売が表示されますが、販売には顧客が表示されません。
ナビゲーションの可視性のタイプ
上司と部下の間の 1 対多の関係を表し、通常は上司から部下への関係を指します。
強制関連付け。あるクラスのオブジェクトは、別のクラスのオブジェクトがなければ存在できません。通常は、より独立したクラスから依存クラスに移動します。
例えば、上記の顧客と販売では、顧客がいなければ販売の意味がありません。
あるオブジェクトが別のオブジェクトからの情報を必要とする場合、ナビゲーション矢印が必要になる場合があります
ナビゲーションの可視性は双方向にすることができます
予備的なユースケース図を作成する手順
ユースケースを次々と図に追加
ユースケースに関係するドメイン クラスを選択します (前提条件と事後条件の考え方を参照)
前提条件と事後条件は、第 5 章のユースケースの説明に記載する必要があります。
ユースケースに対応するためにコントローラー クラスを追加する
ガイドラインを使用して、ナビゲーションの初期表示のニーズを決定し、図に追加します。
各クラスのプロパティを可視性と型で詳細に説明する
関連性と多重性は、テキスト内でナビゲーションが強調されるのと同様に、設計クラス図から削除されることがよくありますが、保持されることが多いことに注意してください。
ドメインクラス図から予備設計クラス図へ
10.6 詳細設計での CRC カードの使用
CRCカードは階級、責任、協力を意味します
オブジェクト指向の設計では、クラスに責任を割り当て、それらがどのように連携してユースケースを完了するかが重要です。
CRC カードは、クラス名、責任名、連携クラスの 3 つの領域に分かれています。
CRCカードを使用する手順
未使用の CRC カードのセットから始めて、次から次へとユースケースを進めていきます。
ユースケースを選択し、そのコントローラーとしてカードを選択します
この使用例を主に担当するドメイン クラスを決定します。このクラスのオブジェクトは、コントローラーからメッセージを受け取り、その責任をカードの左側に書き込みます。
メイン オブジェクト クラスと連携してユース ケースを完了する他のクラスを特定し、CRC カードの右側に書き込みます。
連携区分を決定したら、連携区分ごとに上記の操作（責任の決定・連携区分の検索）を行う
ユーザーインターフェースクラスやデータベースアクセスクラスを適宜追加可能
CRC カードの結果を使用して、予備設計クラス図を更新します。
メソッドを更新します。CRC カード内の責任はメソッドになります (ただし、可視性と戻り値の型の式はありません。つまり、メソッド特性は追加されません)。
ナビゲーションの可視性を更新する
例
予備設計のクラス図
設計クラス図を更新
10.7 詳細設計のいくつかの原則
低結合
高い凝集力
可変保護
間接的な
オブジェクトの責任
Chapter11 オブジェクト指向設計:設計の実装
11.2 多層システムの詳細設計
デザインパターン
デザインパターン – グッドプラクティスとして広く認識されている標準的なデザインテクニックとテンプレート
一般的なデザイン/コーディングの問題については、デザイン パターンが問題を処理する最適な方法を提案します。
デザインパターンの要素
スキーマ名
解決策が必要な問題
問題解決モデル
パターンケース
パターンの利点と結果
プログラミング設計パターンの最初の例は、コントローラー パターンです。
ユースケース コントローラーは、カップリングを軽減するためにビュー層からドメイン層にメッセージを渡すために人為的に作成されます。
利点と結果
ドメイン層とビュー層の間の結合を軽減します。
間接的な層を提供します
コントローラーとドメインクラスは密接に結合されています
注意しないと、コントローラーには無関係なロジック、特にビジネス ロジックが多数含まれてしまいます。
11.3 ユースケースの実装とシーケンス図 SSD
ユースケースの実装 - インタラクション図を使用してユースケースを詳細に設計するプロセス
相互作用図には 2 種類あります
フローチャート
シーケンス図はシステムのシーケンス図を拡張して表示されます。
ビューレイヤーオブジェクト
ドメイン層オブジェクト (通常は最初に実行されます)
データ アクセス レイヤー オブジェクト
連携図
11.3.1 シーケンス図の理解
システムシーケンス図とシーケンス図の違い
システム シーケンス図にはシステムを表すオブジェクトが 1 つだけあります。一方、シーケンス図はオブジェクトをシステムの内部まで拡張します。
システム シーケンス図にはアクターとシステムを表す 2 つのライフラインのみがあり、シーケンス図内のアクターと各オブジェクトにはライフラインがありますが、長さは異なる場合があります (タイミングはオブジェクトの作成時に開始されます)。
同じユースケースでは、システムのシーケンス図とシーケンス図の自動化境界部分は同じ（全体は変わらない）、つまりシステムへの入力とシステムの外部への出力は同じです。同じ。
シーケンス図には、アクティビティ ライフラインと呼ばれる特別なライフライン セクションがあります。
アクティビティのライフラインは、オブジェクトがアクティブな実行状態にある時間を表します。アクティブな状態は、すべてのデータが保存されるか、他のメソッドが呼び出されるまで続きます。
ユーザー ユース ケースを作成するこのシーケンス図では、Customform と CustomHandler が作成され、Custom オブジェクトが createCustom メソッドの後に作成されるため、ライフラインの開始時間が異なり、長方形のバーがアクティブなライフラインになります。
11.3.2 ユースケース実装の設計プロセス
設計ステップ
ナビゲーションの可視性を示す予備設計クラス図を作成する
CRC カードを使用してユースケースのクラスに関数を割り当てる
ユースケースごとに詳細なシーケンス図を作成する
暫定的なシーケンス図
マルチレベルのシーケンス図
CRC カードと詳細なシーケンス図を使用して、設計クラス図を更新し、メソッド機能を追加します
パッケージデザインのクラス図
11.3.3 ケース: ユーザーアカウントを作成するための予備設計クラス図
以前に作成した予備設計クラス図に基づいて予備シーケンス図を作成します。
システム シーケンス図を展開し、元のシステムで使用する必要があるクラス オブジェクトにマークを付けます。その前にはコロンがまだ残っています。
オブジェクト間の内部メッセージを決定し、メッセージとアクティベーションを追加してコラボレーションを完了します
メッセージの形式は、システム シーケンス図と一致しています。 *[条件] return_value:=function_name(parameter_list) 戻り値として破線の逆矢印を使用することもできます。
サブトピック
11.3.5 予備的なシーケンス図を作成するためのガイドラインと前提条件
ガイド
各メッセージを受け入れ、この入力メッセージから生じる他の内部メッセージを識別します。
各メッセージを処理するときに、影響を受けるクラスのセットを指定します。
メッセージ構造を強化し、true と false の条件、ループ、戻り値、パラメータ転送などを追加します。
仮説
技術的完成仮説
記憶完全性仮説
異常の仮定なし
11.3.6 多層シーケンス図の開発
上記はドメイン層 (論理層) の暫定的なシーケンス図にすぎません。ユースケースをより詳細に説明するには、データ アクセス層とビュー層のシーケンス図を作成する必要があります。
11.4 コラボレーション図コミュニケーション図の使用
11.5 更新とパッケージ設計のクラス図
設計クラス図を更新
シーケンス図の情報に基づいて、メソッド機能を追加して DCD を更新します
3つのメソッドタイプ
コンストラクター メソッド: 新しいオブジェクト インスタンスを作成する
データの読み取りおよび書き込みメソッド: 属性値の取得または更新
ユースケース固有のメソッド: デザインクラス図に含まれています
パッケージマップ
パッケージ図は、関連するクラスのグループを関連付ける高レベルの図です。
フォルダーのようなアイコンを使用してパッケージを表し、クラスは属するレイヤーに応じて対応するパッケージに配置されます。
点線の矢印を使用して、クラス間の依存関係やパッケージ間の依存関係などの依存関係を示します。
例
ユースケースが 1 つだけある部分的なパッケージ図
サブシステムのパッケージ図
11.6 その他の一般的な設計パターン
アダプタ
2 つのシステムを接続する必要があるが、それらの間のインターフェイスが一致しない場合、アダプターが必要になります。
データを書き換えて不一致のインターフェースを接続する
例: 異なるサプライヤー (税金、配送料) に直面する場合、アダプターを書き直すだけで済みます。
工場
ファクトリ クラスは、さまざまなタイプのユーティリティ クラス インスタンスを作成するために使用されます。
通常、ツール クラスに必要なインスタンスは 1 つだけであり、ファクトリはインスタンスが 1 つだけ存在することを保証します。
シングルトン
シングルトンには、それ自体のインスタンスを指す静的変数があります。何らかの方法でこの変数を確認してください。空の場合はインスタンスを作成して変数に割り当てることができ、空でない場合は変数のインスタンスを直接返すことができます。
クラス接続{ プライベート静的 conn=null; public synchronized static getConnection(){ if conn==null{ conn=新しい接続(); } コンを返します。 } }
ファクトリーとシングルトン
ファクトリとシングルトンの基本的なロジックは同じです。両方とも、オブジェクトのインスタンスが 1 つだけ存在することを保証し、メモリのオーバーヘッドを節約することです。
ただし、ファクトリは複数のクラスを管理する必要があります。シングルトンはクラス内の静的インスタンス変数のみをチェックします。