sot11 最近の更新履歴城西国際大学_経営情報学部_組織情報論2017

(1)

組織情報論

第11回ソフトウェア開発手法

1

講師佐枝三郎

https://sites.google.com/site/jiusaedasoshikiron2017/

ソフトウェア開発の手法とは

• ソフトウェア開発とは、顧客の業務（仕事の仕組み）を整理し、仕事

に必要なソフトウェアの中身を明らかにし、実際にそれを構築する

作業である

• ソフトウェア開発手法はいくつかあるが、それぞれの差異は、整理

の仕方の違い、何を中心に見るかの視点の違いである

2

(2)

構造化手法（設計）

• 製品を作る「工学」の基本的なアプローチは、「分割と

統合（Divide and Conquer）」という考え方に基づく

– 新製品を開発する場合、次のような手順で実施する

• 最初に「どのような製品を開発するか」という製品全体のコンセプトを明らかにする

• 次に、大きくて複雑な製品全体を切り分け、より細かい部品（構成要素）に分割する

– 解決するべき問題をより単純な問題に置き換える

• それぞれの部品がまだ複雑で、簡単に解決できない場合は、またそれを細かい部品に繰り返し分割する

– 十分問題が単純になり、その部品の作り方（解決策）が分

かれば、その作り方に従って部品を作成する

• すべての分割した構成要素に対して、この手法を適用する

– 部品が作成できたものから、順次その部品を組み合わせ

た半製品に組み上げる

• これを統合という

• 最終的に製品全体が組み上がるまで、順次統合を繰り返す

3

構造化手法（設計）

• 製品を作る「工学」の基本的なアプローチは、「分割と

統合（Divide and Conquer）」という考え方に基づく

新製品を開発する手順

「どのような製品を開発するか」という製品全体のコンセプトを明らかにする

大きくて複雑な製品全体を切り分け、より細かい部品（構成要素）に分割する

・解決するべき問題をより単純な問題に置き換える

十分問題が単純になり、その部品の作り方

（解決策）が分かれば、その作り方に従って部品を作成する

・すべての分割した構成要素に対して、この手法を適用する

部品が作成できたものから、順次その部品を組み合わせた半製品に組み上げる

・これを統合という

・最終的に製品全体が組み上がるまで、順次統合を繰り返す

4

(3)

構造化手法の特徴

• 構造化手法（設計）は、この「分割と統合」の考え方を

ソフトウェアの開発に適用したものである

– 構造化手法は、「トップ・ダウン・アプローチ」と呼ばれる場

合もある

• 構造化手法は1960年代後半から80年代まで、約20年

間で徐々に発展したものである

– E.ダイクストラが1960年代後半に、Goto文のない「構造化

プログラミング」のパラダイムを提唱した

– G.J.マイヤーズらが1970年代前半に、「モジュール分割」

の概念に基づくソフトウエア構造の設計手法を提案した

– T.デマルコが1970年代後半に、データフローダイヤグラム

とデータディクショナリを提案した

– 1980年代の後半に、E.ヨードンが「近代構造化分析

(Modern Structured Analysis)」という構造化手法全体をま

とめた本を出版した

5

構造化手法の特徴

• 構造化手法のポイント、モジュール化

– モジュール化は、様々な機能を持つ大きなソフトウェ

アを、「1 つの入り口、1 つの出口、1 つの機能」であ

る「モジュール」に分割する

– モジュールを組み合わせ、全体としての複数の機能

を持つ大規模なソフトウェアを実現する

• 構造化手法における設計の目標

– 「モジュールの強度」を最大にし、「モジュール間の結

合度」を最小にするもの

• 「モジュールの強度」とは、個々のモジュール内のステートメ

ント間の関連性をいう

• 「モジュールの結合度」とは、1 つのモジュールと他のモ

ジュールとの関わり方をいう

6

(4)

構造化手法の考え方

• ソフトウェア開発の対象となる領域のデータと機能に着目する

– 機能とデータに分解する

– 機能を段階的に詳細化する

– 上位から詳細化するため「抜け・漏れ」が発生しにくい

• 機能やプロセス（処理）を中心としたアプローチということができる

データ

機能

データソフトウェア全体

詳細化

7

モジュールの強度と結合度

強度レベル特徴

強 ^機能的全ての要素が１つの機能を実行するために関連しあっているもの情報的特定のデータ構造を持つ複数の機

能をまとめたもの

連絡的モジュール内の要素間でデータの受け渡しを行うもの

手順的複数の関連性を持つ逐次的な機能を１つのモジュールにまとめたもの時間的複数の実行時間が同じ逐次的な機

能を１つにモジュール化したもの論理的複数の機能を１つのモジュールにし、

動かすものを外部から指示する形

弱 ^暗号的複数の、無関係な機能をモジュール化したもの

結合度レベル特徴

弱 ^データデータ要素のパラメータ受け渡しでインタフェースを取る

スタンプ２つ以上のモジュールが、共通域にはない同じデータを共有する制御制御要素がパラメータとして渡さ

れる

外部外部宣言しているデータを参照する

共通複共通域のデータ構造を参照する

強 ^内容他のモジュール内のデータを直接参照したり、直接分岐する

モジュールの強度モジュールの結合度

8

(5)

構造化手法で利用するツール

• 整合性を確認しつつ段階的に機能を詳細化する

– データフローダイアグラム

テーブル（表）で網羅的に考える

– デシジョン(決定）テーブル

• 様々な条件の組み合わせで何を行うかを整理したテーブル

– 状態遷移テーブル

• ある物の状態が、条件によってどのように変化するかを整理したテーブル

• デシジョンテーブル、状態遷移表は構造化手法のためのものではなく、独立したツールだが、手法のなかで使用が勧められている。

9

データ中心アプローチ（DOA）

• データ中心アプローチは、Data Oriented Approach（DOA）

の略である

– ソフトウェアの機能ではなく、開発対象の領域にどのようなデー

タが存在するか、それらのデータをどのように利用するかを視

点として、ソフトウェアの開発を行う手法

• データ中心アプローチは、「データは企業の共有資源」と

いう情報資源管理の考え方に基づくもの

– 個別業務の単位ではなく、「全社共有」のデータ基盤を整備す

ることを前提とする

– データ基盤を実際の「共有データベース」と考える手法

• 具体的に複数のアプリケーションが利用する実データを格納するデータベースを構築・整備するという方法

– 「エンタープライズモデル（概念データモデル）」と考える手法

• 実際にメタデータを格納するリポジトリの構築を優先して考える方法

• メタデータとは、データの名前・形式・意味・管理部門などの情報のことであり、データのデータであるから、「メタデータ」という

• リポジトリはそのデータに関する情報を格納するデータベース

10

(6)

データ中心アプローチの発展経過

• 「データ中心」の概念の始まり

– ソフトウェアの設計で、「ファイルやデータの設計を先行するべき

である」という考え方は、「データオリエンテッド」「ファイルオリエ

ンテッド」と呼ばれ、 1960年代から始まった

– 実際のプログラム開発では、プロセス中心アプローチが主流で

あった

• 1960年代のソフトウェアは比較的単純な業務の機械化であ

り、複雑な分析や設計が必要なかったため

– 1970年代では、MIS （経営情報システム）実現の手法としてIBM

のBSP（Business System Planning）、M.ブライスのPRIDE方法論が

登場

– 1970年代末、R.ノーランらが「情報資源管理」「データ資源管理」

を提唱した

11

データ中心アプローチの発展経過

• データベース管理システムの登場と普及

– 1970年にはE.コッドの「リレーショナル・データモデル」、1975年に

はP.チェンの「ERモデル」が登場

– 1980年代には商用のリレーショナルデータベース管理システム

が登場する

• データベース構築を前提とするソフトウェア設計方法論が登

場する

– この方法論が、「データ中心アプローチ（データ中心システム設

計）」である

– C.フィンケルステインとJ.マーチンが提唱したIE(Information

Engineering)

– が有名である。「データ中心アプローチ」もこうした流れの中に位

置付けられる

– 1980年には日本でも、堀内一、椿正明、穂鷹良介などが、様々

なデータモデリング手法を提唱した

12

(7)

「データ中心」と「プロセス中心」

• プロセス中心アプローチ

– 業務のプロセスに合わせて機能の設計を行い、プログラムごとに必要なデータを定義する

– データはプログラム毎の約束、一時的な記憶であり、全体としての一貫性がなく、業務が変わると機能が変わり、それに応じてデータの形式や意味も変わる

• ^{データ中心アプローチ}

– データ中心アプローチは、データ項目やデータ構造は変わりにくいという点に注目した手法

– データ項目は、「事実の記録」であり、「売上」というデータ項目がどのようなものかは会計ルールで定義され、データ項目の意味や定義は簡単には変わらない

• データベースにデータの意味をまとめて管理する

– 企業の様々なシステムの中心にデータを一元管理するデータベースを配置する

• プログラムはデータの入出力先として、ユーザーの画面など以外は、データベースだけを考えればいい

– データベースがすべてのデータを記録していれば、計算結果はいつでも再現可能

• プログラムは中間ファイルなどを持つ必要がなく、プログラムが簡単になる₁₃

「プロセス中心」と「データ中心」

○業務のプロセスに合わせて機能の設計を行い、プログラムごとに必要なデータを定義する

○データはプログラム毎の約束、一時的な記憶であり、全体としての一貫性がなく、業務が変わると機能が変わり、それに応じてデータの形式や意味も変わる

○データ中心アプローチは、データ項目やデータ構造は変わりにくいという点に注目した手法

○データ項目は、「事実の記録」であり、「売上」というデータ項目がどのようなものかは会計ルールで定義され、データ項目の意味や定義は簡単には変わらない

プロセス中心アプローチデータ中心アプローチ

○データベースにデータの意味をまとめて管理する

・企業の様々なシステムの中心にデータを一元管理するデータベースを配置する

・プログラムはデータの入出力先として、ユーザーの画面など以外は、データベースだけを考えればいい

・データベースがすべてのデータを記録していれば、計算結果はいつでも再現可能

・プログラムは中間ファイルなどを持つ必要がなく、プログラ

ムが簡単になる ¹⁴

(8)

データ中心アプローチの特徴

• データ中心アプローチの最大の特徴は、組織全体でデータベース

の共用を可能にしたこと

– 複数システムの処理の中心にデータベースを配置することで、情報システム全体の構造が簡潔になる

• データの発生時にそのデータを受け取ってデータベースに格納し、出力が必要な時にその更新済みのデータベースから必要な出力を作成する

– システムの分析者の個性が情報システムに反映される割合が減少し、構造化技法にくらべ、設計された情報システムの理解が容易になる

• データ中心アプローチによって、情報システムにおけるプログラム

とデータについての考え方が大きく変わる

– 「組織にとって大切なものはデータであり、プログラムではない。プログラムを外部から購入し機能を果たせるなら、自社内でプログラムを作る必要はない。」

– 現在、企業が業務ソフトウェアパッケージを利用する場合が多く、ソフトウェアパッケージの利用はこの考え方に基づく

• ソフトウェア開発手法としての「データ中心アプローチ」は、対象物

（データ）の構造に従って処理（プログラム）を導くという点で、「オブ

ジェクト指向アプローチ」と同様の視点に立つものである

15

オブジェクト指向アプローチ

・オブジェクトとは英語で「もの」を意味する

・現実世界の「もの」になぞらえて、プログラムの部品を作り

それを組み立てて、現実社会と同じようなプログラムを作る

考え方

・オブジェクト指向アプローチの考え方は、

「人を中心とした実社会で行われている仕事の進め方を、コン

ピュータの内部でも実現しようとするもの」

16

(9)

オブジェクト

（定義はクラス、実態はインスタンス）

オブジェクト指向とは

• オブジェクト指向言語では、オブジェクトは「デー

タ」と「手続き」をまとめたものを意味する。

• すなわち、ある「データ構造」とそれを使うため

のプログラム（アルゴリズム）がいっしょになった

「かたまり」をオブジェクトという。

データ構造

（数値変数、文字変数、配列．．．）

メソッド

（関数、データを使って何かの答えを出すプログラム）いくつでも作れる

17

オブジェクト指向の4つの要素

• ①クラスとインスタンス

– オブジェクトの設計図にあたるものをクラス、設計図をもとに具体的に動くオブジェクトをインスタンスという。

– 例えばWORDやEXCELを使うときを考える。PCのデスクトップにある WORDやEXCELのアイコンがクラス。それをクリックしてスクリーンに WORDやEXCELの画面が現れたら、それはWORD,EXCELのインスタンスが一つできたということになる。

– クラスは事前にプログラムとして定義されたものであって、クラスの実体をメモリ上に一個作るという操作が行われてから、はじめてインスタンスができ、クラスで定義された処理内容が実行できる。

クラスA メモリ

クラスB

インスタンスA

インスタンスB

18

(10)

オブジェクト指向の4つの要素

• ^②継承

– あるクラスの定義、すなわちデータ構造やメソッドを引き継いで、定義の一部を変更した新しいクラスを定義することを「継承（Inheritance）」という。

– 継承元のクラスをスーパークラス、新しく作られたクラスをサブクラスという。

– 継承を使うと共通するメソッド（関数）などは元のクラスで定義し、異なる部分だけサブクラスで定義することができる。プログラムを書く手間や、テストをして確認する手間が大幅に省ける。

哺乳類足の数＝4 吠える、鳴く

犬足の数＝4 吠える、鳴く

人間足の数＝2 吠える、話す、笑う

呼ばれる

オブジェクト

オブジェクト指向の4つの要素

• ^{③カプセル化}

– あるオブジェクトの中のメソッドを、外側のオブジェクトから呼び出せないようにする、オブジェクトの中のデータを外側から参照できないようにすることをカプセル化という。外側に見せたい（使ってほしい）メソッドのみをっ窓口経由で公開する。

– カプセル化によって、呼び出すプログラムと呼ばれるオブジェクト、それぞれ独立に開発、変更ができ、プログラムやデータの不整合が起きにくくなる。

呼び出すカプセルオブジェクト

窓口

必ず窓口経由でアクセスするように言語仕様で強制する

社員

・氏名

・性別

・（入社年月日）

・勤続年数

（現在時点と入社年月日から計算される）

呼び出すオブジェクト

勤続年数は

計算結果が返される

(11)

オブジェクト指向の4つの要素

• ④ポリモルフィズム

– 同じ親元を継承した兄弟のクラスで、兄弟クラス間で同じ名前

のメソッドでも、それぞれ異なった処理が行われることをポリモ

ルフィズム（多態性）という。

– 継承したクラス間の詳細な差異を気にすることなく、親元クラ

スで定義した大きな構造や概念でプログラミングができる。

図形

・書く

三角形

・1番目の点の座標

・書く

（各点の座標間に線を記述する）

円

・中心点の座標

・半径

・書く

（中心点の座標を中心として半径分離れた座標に点を 360度分回転して記述する）

オブジェクト指向アプローチに

用いるモデリング

22

(12)

ソフトウェア開発に利用するモデル図

区分目的モデルプロセスモデルエンティティモデル

アプリケーションモデル

インフラモデル業務プロジェクト

コンテキスト図

業務フロー図業務概念オブジェクト図

システム構成図組織図

業務

コンテキスト図

業務情報フロー図

業務概念図

目的構造図状態遷移図システムアクター図システム化業

務フロー図

データ図コンポネント図インフラ図

ユースケース図

ユースケースデータ図

データ容量見積

アーキテクチャ図

ネットワーク構成図要求項目状態遷移図データ項目

定義

23

統一モデリング言語（UML）

• 統一モデリング言語（UML : Unified Modeling Language）は、オブジェクト指向型システム開発で用いる、標準化した仕様記述言語である。

– UMLはシステム化対象の業務手順や、システムの構成、振る舞いを図として記述する汎用モデリング言語である。

– UMLは1995年ごろ、ブーチ、ヤコブソン、ランボーの3名のオブジェクト指向開発の研究者が開発した。

– UMLは、OMG (Object Management Group) が管理し、最新版は2015年の UML 2.5 である。

– UMLの2.4.1版が、ISO/IEC 19501-2:2012 として国際標準化されている。

• UMLでは13種類の図（ダイアグラム）を必要

に応じ利用する。

– 構造図：クラス図、複合構造図、コンポーネント図、配置図、オブジェクト図、パッケージ図

– 振る舞い図：アクティビティ図、ユースケース図、ステートチャート、相互作用図、シーケンス図、相互作用概要図、タイミング図

24

(13)

V 字型モデルにおける主要UML図の利用方法

要件定義

外部設計

内部設計

製造

アクティビティ図フローを記述する図で、フローチャートの一種。UML では表記するフローは特定されておらず、利用者に近い業務のフローを示すことができる。

ユースケース図

利用者の視点から、システムに要求する機能を示した図。ユースケース図を有効に活用することで、システムの全体像を開発者と利用者が一緒に評価できる。

クラス図

システムを構成する概念（クラス）と、その間に存在する関連の構造を表現する。利用者の視点から、システムを構成する物や概念を示す図。

シークエンス図オブジェクト間のメッセージの流れを時系列に表す図。図の中に時間の流れがあるため、イベントの発生順序やオブジェクトの生存状況を表せる。

UML で作成する主要なモデル図

25

アクティビティ図とは

• アクティビティ図は、フローチャートに似た図で、上流行程のビジネスプロセスの流れや下流行程のプログラムの制御フローを表すことができる UMLの図である。

• フローチャートのUML版という位置づけで、UML 1.0で採用され、UML2.0 で記述可能な範囲が大きく拡張された。

• アクティビティ図は、連続する「処理」の遷移、一連の｢手続き｣が表現でき、ある事象の開始から終了までの手続きを実行される順序にしたがって記述する。

• 状態マシン図が実体の状態の遷移を表現するのに対し、アクティビティ図では実体の制御の流れを記述する。

• アクティビティ図は、フローチャートと異なり、並列の振る舞いやオブジェクトなども表現できる。

• アクティビティ図は、プログラムでの処理以外にも、業務フローなどの記載も可能であり、業務手続きの可視化や、新業務の設計に用いられる。

26

(14)

アクティビティ図の記述方法 ①

〇連続的な処理の手順例

（PCを製造するケース）

部品を準備する

開始

PCを組み立てる完了検査をする

アクティビティ遷移終了

27

アクティビティ図の記述方法 ②

〇並行的な処理の手順例

（PCを製造するケース）

同期バー

（fork）

PCを組み立てる完了検査をする

同期バー

（join）筐体を準備する

マザーボードを準備する

複数の人が、別の部品を準備する場合は、並行的な処理になる。

並行して開始できるところが「fork（分かれる）」別々の処理の結果をまとめるところが「join

（まとめる）」というバーで表す。

28

(15)

アクティビティ図の記述方法 ③

〇作業分担

人や組織で担当する処理（作業）を分けて表現する。

筐体への部品取付マザー

ボード取出

マザーボードメモリ取付

マザーボード CPU取付

筐体の用意

完了検査

［取付部品が不足］

［部品は存在］

不足部品の調達

課長ボード係組立係検査係調達係

マザーボード

取付ケーブル

設定ディスプ

レーなど用意

OS インストール

29

企業の受注業務のアクティビティ図

• 卸売業の販売管理業務にアクティビティ図を適

用する。

• 組織・システムの区分としては、次の四つを使用

– 顧客

– 営業部門

– 倉庫部門

– システム

• 業務の流れとしては、顧客が注文をしてから、商

品が納品されるまでを表現

30

(16)

31

ユースケースモデルとは

• ユースケースモデルは、「ユースケース図」と「ユース

ケース記述」の二つから構成される。

• ユースケース図：

– 人形のマークはアクターといい、長円のマークをユースケースという。 – アクターは、ある役割を持ちシステムを利用する人あるいはもの（オブジェク

ト）である。

– アクターは、システムを利用しようとする何らかの役割と考えればよい。 – ユースケースは、システムの利用方法であり、次ページの図ではユーザーが

「商品を買う」、「買った商品を確認する」というシステムの利用方法がある。 – 商品販売システムと描かれた長方形はシステム境界であり、システムの内外

を明確に分ける。

– アクターは、システム境界の外部に存在し、ユースケースはシステム境界の内部に存在する

– アクターとユースケースをつなぐ線を関連と呼ぶ。

32

(17)

ユースケース図の例

33

ユースケース記述

• ユースケース記述は、ユースケース図にある、1

つのユースケースに対して、アクターとシステム

のやりとりをストーリーとして記述したものである。

ユースケース名商品を買う

概要本ユースケースは、Web上および店頭で商品を買う際に呼び出される。店頭では、店員を通じて本ユースケースが利用される

アクター Webユーザ、店員（ユーザの代理でシステムを操作）

メインフローアクターシステム

購入したい商品のジャンルを選ぶ選択されたジャンルの商品一覧を返す

商品を選ぶ商品の詳細情報（説明、金額、

写真）を返すこの商品でよければ商品購入手

続きに入る

34

(18)

メインフロー以外のユースケース記述

• ユースケース記述は、メインフロー以外に、代替フロー（メインフローの条件分岐）、例外フロー（ユースケース中の例外的な挙動）を記述できる。

• ユースケース記述は、ユースケースを呼び出すために必要な条件である

「事前条件」や、ユースケースが終了する際にシステムが行うべき「事後条件」も記述可能である。

• アクターやシステム利用者の説明のために、「シナリオ」を記述することもある。

ユースケース名商品を買う（具体的に礼服を買うシナリオ）メインフローの

シナリオ例

アクターシステム

紳士服ジャンルを選ぶ紳士服の一覧を表示する

気に入った礼服を選ぶ選択された礼服の説明、サイズ、金額、写真を表示する

この礼服の購入手続きに入る

35

外部設計と内部設計で用いるモデリングのモデ

外部設計

内部設計

ユースケース図利用者の視点から、システムに要求する機能を示した図。

クラス図システムを構成する概念（クラス）と、その間に存在する関連の構造を表現する。

シークエンス図オブジェクト間のメッセージの流れを時系列に表す図。

利用者が使う画面の構造と詳細なシステムの動きを設計する。

UIフロー図ロバストネス図

利用者の視点から、システムに必要な画面を抽出し、その遷移を示した図。

利用者の視点から、システムに必要なUI、エンティティ、コントローラを示した図。

画面設計

（UI設計）データベース設計

（エンティティ設計）

利用者が使うデータベース（エンティティ）の構造と詳細なデータ項目を設計する。

36

(19)

クラス図によるモデリング

• クラス図はUML図の一つで、システムの構造を表すものであり、対象とする世界が「どうであるか」をモデリングする方法である。

• クラス図は、データモデリングのE-R図と同様に、対象とする世界を理解するための道具である。

– クラス図はプログラム設計のためだけのものではないが、オブジェクト指向言語の概念はクラス図で利用される概念が言語仕様の重要な部分を占めている。そのため、クラス図のモデリングが、オブジェクト指向言語の基本構造設計になっていく場合が多い。

• クラス図はオブジェクトとその「静的」な関係を間の関係を描いたものであり、動的な「振る舞い」は他の図で描かれる。

– 対象の世界が「どうであるか」を示す図であって、「どう動くか」を示す図ではない。 – クラス図は、ある時点でのオブジェクト間の関連や、それぞれのオブジェクトがどのよう

な属性を持つかを示している。

– 対象世界の理解(設計）は、時間の経過によって変化が少ない、骨格的な構造をとらえるようにする。

• 動的な側面（どう動くか）を記述するには、シークエンス図や状態遷移図を使用する。

37

クラス図の書き方 ①

• クラス図の基本的な概念は、データモデリングのE-R図に非常によく似ている。次にER図との対応でクラス図の概念を説明する。

項目クラス図 E-R図備考

概念そのものクラスとして、長方形の箱に記述

エンティティとして、長方形の箱に記述

概念としては全く同様で、 EXCELの表全体で表現できるような内容

属性クラスの持つ状態の情報として、クラス内に記述

エンティティの持つ情報として、エンティティ内に記述

概念としては全く同様で、 EXCEL表の項目で表現できるような内容

関連クラスとクラスの関係であり、それぞれを結ぶ線と付属情報で記述

エンティティとエンティティの関係であり、それぞれを結ぶ線と付属情報で記述

・カーディナリティ 1：1、1:nなど

・依存関係はどちらも記述する。

操作（メソッド） _{クラスの持つ機能の情} 報として、クラス内に記述

なし _{クラス図のみが操作の}

情報を持つ。

38

(20)

クラス図の書き方 ②

• クラス図の基本的な概念は、データモデリングのER図に非常によく似ている。次にER図との対応でクラス図の概念を説明する。

項目クラス図 E-R図備考

汎化-特化クラス間の汎化ー特化

（概念の親子関係）の情報として、特別な線で表現する。

なし

集約・コンポジション

クラス間が全体と部分である関係の場合に、特別な線で表現する。

なし全体がなくなると部分もなくなる場合がコンポジションである。

実現ある（サブ）クラスが元の

（抽象）クラスの内容を具体化したものである時に、この関係を「実現」と呼び、特別な線で表現する。

なし

クラスA クラスB

39

クラス図の記述例

40

(21)

大学業務のクラス図

41

シークエンス図と状態遷移図による

モデリング

• シーケンス図と状態遷移図は、UML図の中でシステム内部の振舞いを表現するためのものである。

• シーケンス図は相互作用図であり、ユースケースごとにシステム内部のオブジェクト間のやり取りを設計するために用いる。

– シークエンス図は、オブジェクト間のメッセージのやりとりを、時系列に沿って表現する。

• シークエンス図で登場するオブジェクト

– 要求定義段階では、ユースケース図を詳細化したロバストネス図に登場する、「バウンダリ

（画面の候補）」、「エンティティ（データベースのエンティティの候補）」、「コントロール（制御機のjの候補）」レベルで記述する。

– 内部設計段階では、詳細なクラス図で登場する各クラスのオブジェクト（インスタンス）レベルで記述する。

• 状態遷移図（ステートチャート図）は、特定のオブジェクトに焦点を当て、それの状態が相互作用の中でどのように遷移するかを表現する。

– 複雑な状態を持つオブジェクトの分析、業務のワークフローの分析などに用いられる。 – 機器などの制御系システムの設計をする場合には必ず利用される。

– オブジェクト指向設計では、イベントに応じてオブジェクトが起動されるので、状態遷移図を描くことで厳密な設計ができる。

42

(22)

シークエンス図の書き方 ①

• シーケンス図の相互作用は、オブジェクト間のメッセージのやりとりで表現され、図に登場する要素に以下のものがある。

項目説明記号

オブジェクト (object)

クラス概念が実体となった一つをオブジェクト(インスタンス）と呼ぶ。長方形の中に、「オブジェクト名:クラス名」で記述し、名前の一部を省略して、「オブジェクト名」や「:クラス名」と記述することも可能。

ライフライン (lifeline)

オブジェクトが生存している期間を示す点線で、オブジェクトから垂直方向に伸びる。点線の先に×が現れるまでが生存期間である。

A君：学生

43

シークエンス図の書き方 ②

• シーケンス図の相互作用は、オブジェクト間のメッセージのやりとりで表現され、図に登場する要素に以下のものがある。

項目説明記号

メッセージ (message)

ライフライン間を結ぶ水平の矢印（左右OK）とメッセージ名で表現。矢印は同期と非同期の2種類があり、先端の形状が異なる。

・同期的なメッセージは黒三角の塗りつぶし同期的と、メッセージのリターンを待って次の処理に進むような場合で、通常の関数呼び出し。

・非同期的なメッセージは「＞」のみ

非同期的は、リターンを待たずに次の処理に進む場合で、例えば受け側が別のスレッドで動いており、キューにメッセージを貯めているような場合。

リターン(return) 破線の矢印で表し、返り値を記述する。リターンは省略可能。

活性区間 (activation)

ライフラインの上に上書きされる長方形で、この区間では、そのオブジェクトに制御が移り，オブジェクトがアクティブな状態になっていることを示す。

同期の場合

非同期の場合画面表示（）

メッセージ送信（）

戻り値を返す

44

(23)

シークエンスの例 ^{ー画面の制御ー}

画面Aで利用者が入れたデータを、画面Bに表示し確認を求めるケース

45

sot11 最近の更新履歴 城西国際大学_経営情報学部_組織情報論2017

組織情報論

第11回 ソフトウェア開発手法

講師 佐枝三郎

https://sites.google.com/site/jiusaedasoshikiron2017/

ソフトウェア開発の手法とは

• ソフトウェア開発とは、顧客の業務（仕事の仕組み）を整理し、仕事

に必要なソフトウェアの中身を明らかにし、実際にそれを構築する

作業である

• ソフトウェア開発手法はいくつかあるが、それぞれの差異は、整理

の仕方の違い、何を中心に見るかの視点の違いである

構造化手法（設計）

• 製品を作る「工学」の基本的なアプローチは、「分割と

統合（Divide and Conquer）」という考え方に基づく

– 新製品を開発する場合、次のような手順で実施する

– 十分問題が単純になり、その部品の作り方（解決策）が分

かれば、その作り方に従って部品を作成する

– 部品が作成できたものから、順次その部品を組み合わせ

た半製品に組み上げる

構造化手法（設計）

• 製品を作る「工学」の基本的なアプローチは、「分割と

統合（Divide and Conquer）」という考え方に基づく

新製品を開発する手順

構造化手法の特徴

• 構造化手法（設計）は、この「分割と統合」の考え方を

ソフトウェアの開発に適用したものである

– 構造化手法は、「トップ・ダウン・アプローチ」と呼ばれる場

合もある

• 構造化手法は1960年代後半から80年代まで、約20年

間で徐々に発展したものである

– E.ダイクストラが1960年代後半に、Goto文のない「構造化

プログラミング」のパラダイムを提唱した

– G.J.マイヤーズらが1970年代前半に、「モジュール分割」

の概念に基づくソフトウエア構造の設計手法を提案した

– T.デマルコが1970年代後半に、データフローダイヤグラム

とデータディクショナリを提案した

– 1980年代の後半に、E.ヨードンが「近代構造化分析

(Modern Structured Analysis)」という構造化手法全体をま

とめた本を出版した

構造化手法の特徴

• 構造化手法のポイント、モジュール化

– モジュール化は、様々な機能を持つ大きなソフトウェ

アを、「1 つの入り口、1 つの出口、1 つの機能」であ

る「モジュール」に分割する

– モジュールを組み合わせ、全体としての複数の機能

を持つ大規模なソフトウェアを実現する

• 構造化手法における設計の目標

– 「モジュールの強度」を最大にし、「モジュール間の結

合度」を最小にするもの

• 「モジュールの強度」とは、個々のモジュール内のステートメ

ント間の関連性をいう

• 「モジュールの結合度」とは、1 つのモジュールと他のモ

ジュールとの関わり方をいう

構造化手法の考え方

• ソフトウェア開発の対象となる領域のデータと機能に着目する

• 機能やプロセス（処理）を中心としたアプローチということができる

モジュールの強度と結合度

構造化手法で利用するツール

• 整合性を確認しつつ段階的に機能を詳細化する

– データフローダイアグラム

テーブル（表）で網羅的に考える

– デシジョン(決定）テーブル

– 状態遷移テーブル

データ中心アプローチ（DOA）

• データ中心アプローチは、Data Oriented Approach（DOA）

の略である

– ソフトウェアの機能ではなく、開発対象の領域にどのようなデー

タが存在するか、それらのデータをどのように利用するかを視

点として、ソフトウェアの開発を行う手法

• データ中心アプローチは、「データは企業の共有資源」と

いう情報資源管理の考え方に基づくもの

– 個別業務の単位ではなく、「全社共有」のデータ基盤を整備す

ることを前提とする

– データ基盤を実際の「共有データベース」と考える手法

– 「エンタープライズモデル（概念データモデル）」と考える手法

データ中心アプローチの発展経過

• 「データ中心」の概念の始まり

– ソフトウェアの設計で、「ファイルやデータの設計を先行するべき

である」という考え方は、「データオリエンテッド」「ファイルオリエ

ンテッド」と呼ばれ、 1960年代から始まった

sot11 最近の更新履歴城西国際大学_経営情報学部_組織情報論2017

第11回ソフトウェア開発手法

講師佐枝三郎

– この方法論が、「データ中心アプローチ（データ中心システム設

• ^{データ中心アプローチ}

プロセス中心アプローチデータ中心アプローチ

・オブジェクトとは英語で「もの」を意味する

・現実世界の「もの」になぞらえて、プログラムの部品を作り

• ^②継承

• ^{③カプセル化}