開発技術(3)

システム設計

システムの設計手法

プロセス中心設計・データ中心設計

プロセス中心設計

業務プロセス(処理)に着目して、システムを設計する方法
業務内容が変更された場合、システムを大幅に変更する必要がある
プロセスモデリングを行う

データ中心設計

業務で行うデータ(情報)の構造に着目してデータベースを作成し、それに基づきシステムを設計する方法
データ構造は業務内容が変更になっても変わらないことが多いのでシステムの改変が容易になる
データモデリングを行う

構造化設計

システムを個々の処理に分割し、階層的な構造にして設計する方法

機能の分割と構造化

メリット
●上位レベルから機能を分析し、コンポーネント単位に分割するので、必要な
　機能の不足を防止可能
●構造化をすることで、システムの中でどのような部分の機能なのかがわかり
　やすい
●よく使うコンポーネントを部品化しておけば、その部品を再利用しやすい

機能の分割

コンポーネントの分割と構造化

コンポーネントの分割

構造化設計の手法

処理の流れを明確にする

●流れ図
●DFD
●状態遷移図

機能や流れを明確にする

●ジャクソン法
●ワーニエ法

その他

名称	説明
構造化チャート	コンポーネントの構造を階層構造で表現するときに使用する図。コンポーネントを構成するモジュールの階層構造や、モジュール間のインタフェースを表現
NSチャート	モジュールの処理内容を表現する図。順次や選択、繰り返しの３つの基本構造だけで構成
HIPO(ハイポ)	システムを階層的に表現する手法。システム階層構造を表現する図式目次と、サブシステムの入力、処理、出力の詳細を記述したIPOダイアグラムからなる

オブジェクト指向設計

オブジェクトと呼ばれる単位でシステムを設計する方法
オブジェクト：属性とメソッド(操作)を持つ
属性：オブジェクトが固有に持つデータ
メソッド：データに対する処理(機能)

情報隠ぺいとカプセル化

カプセル化(隠蔽)は、オブジェクトの性格を決めるデータ構造や値を隠蔽し、オブジェクトの外部から直接アクセスすることを禁止することであり、それにより、オブジェクトのデータ構造やメソッドを変更した場合でも、外部への影響を避けることができ、オブジェクトの独立性を向上させることができる。また、オブジェクトの再利用が容易になる
情報隠ぺい：ほかのオブジェクトによって直接属性を変更できないようにすること
　　　　　　　⇒オブジェクトの独立性を高めることが可能
カプセル化：属性とメソッドを一体化し、情報隠ぺいを実現すること

メッセージ

オブジェクトはその手続きを実行させるための作業依頼を受けると動作する
また、必要なら他のオブジェクトに対してメッセージを出して動作させることもある

クラス

クラス　　　：属性とメソッドをまとめてオブジェクトのひな型を定義したもの
　　　　　　　　(オブジェクトのテンプレート)
インスタンス：クラスから作成されるオブジェクトのこと

抽象化

複数の対象から共通の特徴を抜き出して一般化すること
複数のオブジェクトを抽象化してクラスを定義する

クラスの部品化と再利用

よく利用するクラスを部品化しておくと、そのクラスを再利用できる
対象のクラスを「パッケージ」にまとめる

名称	説明
集約	複数のクラスをひとつのクラスにまとめること
分解	ひとつのクラスを複数のクラスに分けること

継承

スーパークラス(基底クラス)：基準になるクラス
サブクラス(派生クラス)　　：新しく作成するクラス
継承(インヘリタンス)　　　：スーパークラスからサブクラスを作成すること
　　　　　　　　　　　　　　作成方法⇒汎化、特化

名称	説明
汎化	サブクラスの性質も分析・整理してスーパークラスを作成すること
特化	スーパークラスをもとにサブクラスを作成すること

ポリモフィズム

同じメッセージを複数のオブジェクトに送信したとき、複数のオブジェクトがそれぞれ異なる動作をすること。クラスを継承するときに、スーパークラスのメソッドをサブクラスで再定義することによって、異なる動作をさせることが可能

デザインパターン

デジタルパターン：オブジェクト指向設計に深くかかわってきた人の設計ノウハウを蓄積して、設計パターンとして利用できるようにしたもの
●生成に関するパターン
●構造に関するパターン
●振る舞いに関するパターン

UML

ソフトウェアの機能や構造を決定する段階で利用される図の表記方法のこと

クラス図

クラスの構造やクラス間の関係を表現する図のこと
●一番上にクラス名、2番目に属性、3番目にメソッドを記載
●関連の両端の位置に関連についての「ロール名(役割名)」必要に応じて記述

●クラスの関連は、1対多は「1対＊」、0以上多は「0..＊」と表記
●属性と操作性の前には可視性を表記
　○＋：すべてのクラスから直接アクセス可
　○－：対象の属性を持つクラス以外からはアクセス不可
●ロール名を記述

クラス図での集約関係や継承関係

●集約関係：部分クラスから全体クラスに対して◇付きの直線を引く
●継承関係サブクラスからスーパークラスに対して、△付きの直線を引く

ユースケース図

システムには、どのようなアクター(利用者)が存在するのか、それぞれのアクターにはどういった操作(ユースケース)をするのかを記述できる。一般的に、ユースケース図はシステムの要求を定義する際に利用される

①アクターはシステム境界の外側に描く
②ユースケースはシステム境界の内側に描く
③アクターとユースケースを関連でつなぐ

シーケンス図

システムの振る舞いを動的に表現するダイアグラムのひとつ。システムのある場面におけるオブジェクトの動きやメッセージパッシングを、時系列に沿って表現するのに用いる。シーケンス図では、オブジェクト同士の関係性は記述しない

オブジェクト図

ある時点におけるオブジェと同士の関係を表現する図

コラボレーション図

オブジェクト同士の接続関係に着目して、オブジェクト間のメッセージの流れを表現する図

ステートチャート図

時間の経過とともにオブジェクトの状態を表現する図

レビュー

プロジェクトの課程において、上位者が下位者の作成した成果物を確認し、修正指示や承認を与える作業。モニタリングと区別して、特定の資料や分析データといった成果物に対して用いられる

名称	説明
デザインレビュー	開発における各フェーズの成果物を、複数の人にチェックしてもらったり、その成果物を使って検討したりする行為を体系化したもの。「設計レビュー」
ウォークスルー	プログラムの仕様やプログラムそのものに誤りがないかどうかを、プログラム全体にわたってチェックすること
インスペクション	ソフトウェア開発の各作業工程で、設計仕様書やコーディングしたプログラムのロジックを第三者が検証し、誤りや問題点を検出すること
コードレビュー	ソフトウェア開発工程で見過ごされた誤りを検出・修正するためにソースコードの体系的な検査(査読)を行うこと

ソフトウェアの品質

標準規格JISSX0129に沿って、ソフトウェアの品質を評価するときは、品質特性が基準となる

品質特性	説明
機能性	ソフトウェアに求められる機能がしっかりと盛り込まれているのかの度合い
信頼性	正しく動作するかどうかの度合い
使用性	使いやすいかどうかの度合い
効率性	どれくらい少ない資源で動作するかの度合い
保守性	修正がしやすいかどうかの度合い
移植性	簡単に別環境に移せるかどうかの度合い