開発技術(2)
システム設計
構造化分析／設計
プロセス中心アプローチ
業務手順やデータの流れに注目して、機能要件を定めていくシステム設計の考え方。モデリングにはフローチャートやDFD(data flow diagram)、構造化チャートなどが使われる
| 現物理モデル | 現行業務プロセスを調査・把握し、DFD等にまとめる |
| 現論理モデル | 現行物理モデルから機能階層図を作成し業務の本質を明確にする |
| 新論理モデル | 現行論理モデルから統廃合や要求追加により新機能階層図を作成する |
| 新物理モデル | 新論理モデルからデータの正規化などを経て新業務システムを構築する |
DFD(データフロー図)
データの流れに着目して、プロセスを分析する手法。構造化分析／設計では、業務分析のための中心的な技法として使用
データの流れを中心に、データを加工するプロセスとデータストアを段階的に表現する
★DFDの表示例
BPMN(Business Process Modeling Notaion)
すべての関係者が業務の流れ(ワークフロー)容易に理解できることを目的とした標準表記方法。元々の目的がビジネスプロセスのモデリングであったため、それ以外の用途(組織モデル、データモデル等)には適していない。また、業務の流れを表すためのものであり、業務の実施状況や実績など定量的に把握することはできない
データ中心分析／設計(DOA)
データとその操作を中心に分析／設計を行う方法論。業務において、やり方が変わってもデータ自体は大きく変化しないことから、データを中心にとらえ、プロセスはデータを操作するものという考え方で分析／設計を行う。データモデリングが重要となる。E-R図を使って表現する
ジャクソン法
データ構造と処理構造の図式表現を用いたプログラムの設計法
①データ木構造図を作成
②プログラム木構造図を作成
③詳細機能をプログラム木構造図に割り付ける
④プログラムテキストを作成
オブジェクト指向分析／設計(OOA／OOD)
| オブジェクト指向 | ：データとそのデータに対する操作(メソッド)を |
| 一体とした「オブジェクト」単位で扱うこと | |
| オブジェクト指向分析／設計 | ：業務やプログラムをオブジェクト単位で扱う |
| オブジェクト | ：属性(データ)とそれを扱う操作(メソッド)を |
| カプセル化したもの。カプセルの内容は | |
| ブラックボックスとなり外部からは隠蔽される |
クラス
オブジェクトの定義情報。オブジェクト名、どのような属性のデータか、どのような振る舞いのメソッドかという情報を定義する
クラス相互の関係
●汎化／特化(is-a)
一般的な概念と詳細な(具体的な)芸稔との関係に着目する
(例)自動車とスポーツカー
| 名称 | 説明 |
|---|---|
| 汎化 | サブクラスの性質も分析・整理してスーパークラスを作成すること |
| 特化 | スーパークラスをもとにサブクラスを作成すること |
●集約化／分解(part-of)
全体的な概念とその部分的な概念との関係に着目する
(例)自動車とタイヤ
| 名称 | 説明 |
|---|---|
| 集約 | 複数のクラスをひとつのクラスにまとめること |
| 分解 | ひとつのクラスを複数のクラスに分けること |
●所有(has-a)
あるオブジェクトが別のオブジェクトを内包する関係に着目する
(例)自動車と乗客
継承(インヘリタンス)
オブジェクト指向の特徴。クラスの継承。クラスは階層構造をとり、下位クラスは、上位クラスのデータやメソッドを継承することができる。自身で再定義しなくても使用可能となり、ソフトウェアの生産性が向上する
スーパークラス／サブクラス
スーパークラス(基底クラス)：基準になるクラス、上位のクラス
サブクラス(派生クラス) ：新しく作成するクラス、下位のクラス
インスタンス
クラスで定義したオブジェクトが実際に値を持つこと。実例
オーバーライド
スーパークラスの操作(メソッド)を、サブクラスで再定義すること
ポリモフィズム(多態性、多相性、多様性)
同じメッセージを送っても、受け取るオブジェクトによって異なる動作をすること
カプセル化
データとデータに対するメソッド一体化して定義し、データへのアクセスは決められたメソッドだけで行うようにすること。情報隠蔽
静的結合
メソッドの呼び出し方法の一つ。送られてきたメッセージに対するメソッドの特定を、コンパイル時に決定する方法
動的結合
メソッドの呼び出し方法の一つ。送られてきたメッセージに対するメソッドの特定を、実行時に決定する方法。同じメッセージを送っても、受け取るオブジェクトによって異なる動作をする(ポリモフィズム)
多重継承
スーパークラスで定義された性質を、複数のスーパークラスから引継いで新しいクラスを定義すること
委譲
あるオブジェクトに対する操作を、その内部でほかのオブジェクトに依頼する仕組み
論理データモデル作成
トップダウンアプローチ
概念データモデルからシステム化の対象範囲を切り出し、それを具体化、詳細化して論理データモデルを構築する。初めに“こうあるべきだ”という理想論を掲げ、それを実現するために詳細化を進めていく。本来あるべき姿がモデル化できるが、充分にユーザニーズをくみ上げきれていない場合もある
| ①情報戦略、新規システム要件の分析 | →概念データモデル作成 |
| ②業務処理に必要なデータ項目の分析 | →より詳細な概念データモデル作成 |
| ③エンティティの正規化 | →論理データモデル作成 |
ボトムアップアプローチ
エンドユーザが使用している現状の画面や帳票を分析して、抽出されたデータ構造を正規化・統合化することによって論理データモデルを構築する。初めに“現状はこうである”ということを確認し、それを実現または改善するために統合化を進めていく。分かりやすく漏れの少ないモデルを作成可能だが、理想の形をみつけにくい
| ①追加システムの要件分析とユーザビューの正規化 | →現論理データモデル作成 |
| ②エンティティとデータ標準、情報戦略の整合 | →概念データモデル作成 |
| ③エンティティの再正規化 | →新論理データモデル作成 |
UML
統合化された標準的なオブジェクトモデリング技法
| 構造図 | クラス図 | クラスの仕様(属性、操作)とクラス間の関係(関連、汎化、集約)を表した図 |
|---|---|---|
| オブジェクト図 | インスタンスとそん関係を表した図 | |
| パッケージ図 | モデルの要素の分類を表した図 | |
| コンポジット図 | クラスの内部構造を表した図 | |
| コンポーネント図 | コンポーネントを表した図 | |
| 配置図 | システムの物理的な構造を表した図 | |
| 振る舞い図 | ユースケース図 | システムのユースケースを表した図 |
| アクティビティ図 | アクションの実行順序を表した図 | |
| 状態マシン図 | 状態と状態遷移を表した図 | |
| 相互作用図 | シーケンス図 | クラス間の相互作用を時系列に表した図 |
| コミュニケーション図 | クラス間の相互作用をクラス間の関係に着目して表した図 | |
| 相互作用概要図 | 相互作用の状態順序を表した図 | |
| タイミング図 | 相互作用と状態遷移の時間制約を表した図 |
振る舞い図
オブジェクトがどのような振る舞いをするか、動的なオブジェクトの様子を表す図
| ユースケース図 | ：システムの振る舞いと外部の関係を示す |
| ステートチャート図 | ：あるオブジェクトの振る舞いを示す |
| アクティビティ図 | ：状態遷移に着目して処理手順を表す |
▼ユースケース図
システムには、どのようなアクター(利用者)が存在するのか、それぞれのアクターにはどういった操作(ユースケース)をするのかを記述できる。一般的に、ユースケース図はシステムの要求を定義する際に利用される
①アクターはシステム境界の外側に描く
②ユースケースはシステム境界の内側に描く
③アクターとユースケースを関連でつなぐ
静的構造図
対象の静的な構造を表すモデル。クラス図とオブジェクト図がある
▼クラス図
クラスの構造やクラス間の関係を表現する図のこと
●一番上にクラス名、2番目に属性、3番目にメソッドを記載
●関連の両端の位置に関連についての「ロール名(役割名)」を必要に応じて記述
| ●クラスの関連は、1対多は「1対＊」、0以上多は「0..＊」と表記 ●属性と操作性の前には可視性を表記 ＋：すべてのクラスから直接アクセス可 －：対象の属性を持つクラス以外からはアクセス不可 ●ロール名を記述 |
相互作用図
オブジェクト同士が、どうような協調をするかを表すモデル
| シーケンス図 | ：オブジェクト間のメッセージのやり取り(相互作用)を |
| 時系列に表したもの | |
| コラボレーション図 | ：オブジェクト間の役割(ロール)と関係(リンク)を表す |
| コミュニケーション図 | ：クラスやオブジェクト間の応答(相互作用)と関連の |
| 両方を表現する図 |
▼シーケンス図
システムの振る舞いを動的に表現するダイアグラムのひとつ。システムのある場面におけるオブジェクトの動きやメッセージパッシングを、時系列に沿って表現するのに用いる。シーケンス図では、オブジェクト同士の関係性は記述しない
実装図
システムが具体的にどのように実装されるかを表すモデル
| コンポーネント図 | ：ソフトウェアのモジュール構成を記述する |
| 配置図 | ：コンポーネントをどのノードに配置するかを示す |
E-R図
実体である「エンティティ(Entity)」と、関連を表す「リレーションシップ(Relationship)」を使い、データの関連を図で表現する手法。実体関連図などとも呼ばれる
モジュールの設計
分割されたコンポーネントをモジュールの単位まで分割する
モジュールの分割手法、分割基準を踏まえて実施し、モジュールの処理内容や、分割したモジュール間の入出力インタフェースを明確にする
モジュール(ソフトウェアユニット、クラス)
コンポーネントを構成する最小単位のこと
モジュールの分割手法
データの流れに着目したモジュール分割
| 名称 | 説明 |
|---|---|
| STS分割 | 「源泉」「変換」「吸収」の3つのモジュールに分割する方法 ●源泉(Source)：データの入力処理をする部分 ●変換(Transform)：データの変更処理をする部分 ●吸収(Sink)：データの出力処理をする部分 |
| TR分割 | トランザクションの種類ごとにモジュールとして分割する方法 |
| 共通機能分割 | 共通する機能を取り出し、共通モジュールとして分割する方法 共通する機能を共通モジュールとして利用できるので効果的 |
データの構造に着目したモジュール分割
| 名称 | 説明 |
|---|---|
| ジャクソン法 | 入力データと出力データの構造を対比させ、主に出力データの構造をもとにモジュールを分割する方法 |
| ワーエニ法 | 入力データが「いつ、どこで、何回」使われるかをもとにモジュールに分割する方法 |
モジュールの分割基準
モジュール同士の関係に着目し、基本的にモジュールの独立性を高くするように考慮する
モジュールの強度
モジュールの結合度
分割量
コンポーネントのステップ数(行数)を基準にして、モジュールを分割する方法のこと。モジュールが大きくなり過ぎないようにするため、ステップ数に制限を設ける。制限を超えた場合は、モジュールを再分割する
モジュールの部品化と再利用
再利用頻度の高いモジュールを部品化すると開発コストを大幅に削減可能
モジュール仕様書の作成
分割したモジュールについて、モジュールの処理内容や、モジュールのインタフェースなど各モジュール内における使用を記述した「モジュール仕様書」を作成する
流れ図、決定表、ジャクソン法、ワーニエ法、NSチャートなどの手法を用いて作成
マッシュアップ
Web上の機能を組み合わせて新しいシステムを作ること
ソフトウェアの品質
標準規格JISX0129に沿って、ソフトウェアの品質を評価するときには、品質特性が基準となる
| 品質特性 | 説明 |
|---|---|
| 機能性 | ソフトウェアに求められる機能がしっかりと盛り込まれているかの度合い |
| 信頼性 | 正しく動作するかどうかの度合い |
| 使用性 | 使いやすいかどうかの度合い |
| 効率性 | どれくらい少ない資源で動作するかの度合い |
| 保守性 | 修正がしやすいかどうかの度合い |
| 移植性 | 簡単に別環境に移せるかどうかの度合い |
