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

23 

Loading....

Loading....

Loading....

Loading....

Loading....

全文

(1)

組織情報論

10

回 ソフトウェア開発モデル

1

講師 佐枝三郎

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

情報システムのイメージ

• システム開発をする人にとっては

– どのようにシステムを作るか、作る手順を思い浮かべる。

• システムを利用する利用者は

– どのようにシステムを仕事に使うのかという、利用イメージから

思い浮かべる。

• システムを開発することは、利用者にとっては「業務に役

立つ機能や効果を手に入れること」である。

この考え方がシステム開発の

理解には重要

(2)

利用者の立場から見たシステム開発

3

システムとは業務の仕組み

システムとは、ある考え方に基づいた「方法や手順の

体系」を意味する。

システムという言葉は「仕組み」のこと。企業にとって

のシステムは企業にとっては、「業務の仕組み」その

もの

企業のシステムが扱う情報は、「企業の経営者・従業

員が意思決定する、あるいは行動する判断材料とな

るもの」

企業のシステムは、「経営者・従業員が意思決定や行

動を起こす仕組みを提供するもの」

(3)

企業におけるシステム開発の

三つのポイント

従来の企業におけるシステム開発の考え方

新しい「業務の仕組み」を考えること

業務に合わせてコンピュータシステムを作ること

業務を刷新し、その効果・効率を上げること

現在では、「業務の仕組み」を考える場合、既に

あるシステムを要素として考える必要がある

新しい業務に使える

IT

システムは何があるか

業務に合わせてそれらのシステムを組み立て、自社

のシステムにつなげるか

組み立てたシステムで業務が想定した成果を上がら

れたか

5

1

新しい業務の仕組みを考える

• この第一段階は、システムの検討段階は利用者が主体。

• 企業戦略に沿って新しい業務を考え、システムに期待する

ことを明確化する。

• システムエンジニアは「プロセスモデル」や「データモデル」

などのモデルを、UMLなどのモデリング手法を使って表現

し、コンピュータシステムに対する要求をモデル(設計図 面)に整理し記述する。

• 要求のモデル化における検討作業は、上流工程のさらに

上流という意味で「超上流」工程とも呼ばれる。

• システム開発における最も重要な工程として位置付けられ

る。

(4)

2

業務に合わせコンピュータシステムを作る

• 第二段階は、実際に稼働するシステムを構築する過程である

• 第一段階で作成した設計図面を、詳細化した図面にブレークダ

ウンし、最終的にはコンピュータが処理できるプログラムの形 式に変換する

• 設計図面からプログラムを作成し、正しく作成できたかを、確認

する作業はシステムエンジニアとプログラマの仕事である

• 情報システムの機能や構造は、大規模ビル並の複雑度となる

• 最初に決めた要求を設計や構築の段階で変更することは、

様々な面で作業の見直しや、既にできたものの作り直しと再確 認が必要なため、膨大なコストと手間が掛かる

• 企業の業務上の要求は日々変化するが、構築するシステムは

数年以上使うもので、必要な機能だけに絞り込んだシステムを 作ることが費用対効果を高める

7

3

システムを導入し、業務効果・効率を上げる

• 最終段階は、構築されたシステムが確実に要求された機

能を発揮するかのテストを行い、ユーザ側でも提示した要 求を満足しているかの検品・検収を行う

• 合格になった段階で、本番の業務環境に移行する

• 本番システムの運用開始後は、予定の投資効果が得られ

たか、運用費用が過剰でないかなどの評価を行う

• 通常システムの業務に対する効果は、要求を検討した時

の期待された効果を越すことはない

• システムのライフサイクルコストの70%を占める維持・運用

(5)

目的と原理の明確化

• 新システム(新業務の仕組み)が果たす機能や効果は何か、

目的と原理を明示する

– 在庫を減らすために、少量多頻度発注方式に移行する。

– 新たな顧客を獲得するために、インターネット、スマートフォンから購

入できる通販サイトを構築する

• これらのためには、システムの整備と同時に、社員教育や組

織体制の変更など業務の仕組みの改定が必要となる

9

部品 在庫

部品

大量小頻度発注方式 発注点

発注頻度は少ない

部品 在庫

部品

小量多頻度発注方式

発注点

発注頻度は多い 在庫の差

在庫費用の差

要件定義と外部設計

• 新しい業務の手続きや手順を明らかにし、その中でシステム

を利用する部分と利用方法を決め、利用する画面・帳票のデ ザインなども明確化する

• これは「システムへの要求」に基づいて「構築するシステムの

機能内容」を確定することである

• 外部設計とは、業務で利用者が利用するシステムと人間と

のインターフェースの方式を設計することである

– 業務で利用する様々な情報についての定義

• データ項目とその内容、正当な範囲、仕事上の意味

– 利用者が様々な情報を検索したり、データの入力を行う画面の

構成と利用手順

– 利用者が必要とする様々な分析結果の印刷された帳表、およ

び帳票の発行タイミングとサイクル

(6)

システムのアーキテクチャと非機能要件

業務要件と並行して、システムのアーキテクチャと非機

能要件を検討する。

– アーキテクチャとは、ハードウェアやネットワークなどのシス

テムの基本的構造のことである。

– 非機能要件とは、システムの基本性能や信頼性など、業務

内容にかかわらない要件である。パフォーマンス、情報セ キュリティ、信頼性、保守性、可用性などの要件がある。

非機能要件の実現は、システムアーキテクチャによっ

て定まる。

高度な非機能要件は多大な投資が必要であり、業務

上の機能要件との整合性を考えて要件レベルを決める

必要がある。

11

システム技術(

IT)

が新しい業務を作る

新しい業務とは、誰もが考えていなかった商品

やサービスを考え、実現し、提供することからは

じまる

2000

年以後、インターネット、スマートフォン、セ

ンサーなど、様々な

IT

技術が進化している

その結果、「新たな

IT

技術によって、新しいサー

ビスが登場し、新しい業務が生まれ、ニュービジ

ネスが成立する」というプロセスが数多く生まれ

ている

(7)

eBay

インターネットのオークションサイト

インターネットオークション

の先駆け

– 1995年からビジネスを開始

したオークションビジネス の先駆け、1998年には100

人の利用者を獲得

– 現在世界で3億人以上の

会員数、2014年の純売上

高は180億ドル

– 日本でもヤフー、楽天など

のオークションサイトがあ るが、会員規模は最大の ヤフーで700万人程度

インターネット基盤が全世

界で普及したことで成立し

たビジネスの代表例

13

UBER

新しいタクシーシステム

どこかに行きたいお客と、車を

持つドライバーをスマートフォン

のアプリで結びつけ、ニュービ

ジネスとして実現

– 世界中の402都市で利用可能、

東京もその一つ

– 2015年に108億の運賃収入、

UBER社はその20%の手数料収

入の獲得

– スマートフォンのアプリは、地図

で待っている位置を指定できる など、操作性がよい

このビジネスは、スマートフォン

という

IT

インフラが基礎にあるこ

(8)

HAL

世界初のサイボーグ型ロボット

• CYBERDYNE社(筑波大学発ベ

ンチャー)が開発した、身体機 能を改善・補助・拡張すること ができるサイボーグ型ロボット

– 身体の不自由な人をアシストし、

脳・神経系への運動学習を促す

– 業務上大きな力を必要とする作

業の支援をする

– 脳から筋肉に伝達される電気信

号を読み取り、増幅しパワーア シストする

– 2015年、HALは厚生労働省から

医療機器として認定された製品 となる

• 脳科学の成果をソフトウェアと

して実現したIT技術が基礎と

なっている

15

(9)

システム開発プロセスのモデル

• システム開発プロセスの定義

– プロセスには「処理」と「工程」という2つの意味があり、「処理」

は単数形(Process),「工程」は複数形(Processes)で表す。

– 「処理」とは,システムの場合、仕様やデータ,プログラムなど

の「入力」に対して、なんらかの操作をして、結果を「出力」する ことをいう。

– 「工程」は、ある目的を達するために、いくつかの「処理」を順序

正しく実行することをいう。

• システム開発プロセスは、システム開発の「工程」である。

– 開発プロセスは、システム開発で実施する処理とその手順を

定めたものである。

– 各処理の具体的な作業内容を「アクティビティ」、出力する仕様

やプログラム、ドキュメントなどを「作業成果物」と呼ぶ。

17

ウォーターフォール型開発プロセス

1960

年代後半,開発するシステムの大規模化に伴い,

個人の能力や経験のみに頼った方法に限界が生じ,

体系立った開発方法が求められるようになった。

1970

年に米国の

W.W.

ロイスが,ソフトウエアの作成か

ら廃棄までの「ライフサイクル・プロセス」の概念を提

唱した。

ライフサイクル・プロセスでは,開発工程をいくつか

のフェーズ(局面)に分割し,前フェーズの成果物を次

のフェーズの入力とする。

滝が上から下へと流れ落ちるように開発していくこと

から,「ウォーターフォール型開発プロセス」と呼ばれ

る。

(10)

ウォーターフォール型開発プロセス

要件定義

外部設計

内部設計

運用テスト (システムテスト) 製造

結合テスト

総合テスト

システム化要求の調査と分析 システム要件の定義

サブシステムの定義 システム機能仕様の作成 ユーザインターフェース設計 データベース設計 移行・運用設計

プログラム構造設計 プログラム機能仕様の作成 モジュール定義 テスト方針書作成

モジュール仕様作成 コーディング 単体テスト

コンポネント間統合テスト

サブシステム間統合テスト

本番環境による運用確認 障害対応テスト

既存システムとの並行RUN 19

V

字型モデルの考え方

• ウォーターフォール型は,別名「V字型モデル」ともいう。

– 「要件定義」フェーズを左上とし、「製造」フェーズで折り返して

右上へと進むことで「V字型」を形成する。

• V字型の前半部分は「品質を埋め込む段階」、後半は「品

質を確認・検証する段階」と位置付けられ、対応関係がV

字型になるので「V字型モデル」と呼ぶ。

– 「要件定義」フェーズの結果は「運用テスト」フェーズで検証

– 「外部設計」フェーズの結果は「総合テスト」フェーズ検証

– 「内部設計」フェーズの結果は「結合テスト」フェーズで検証

• 建築物や工業製品の製造のほとんどは、ウォーター

フォール型の工程で行われている。

• ウォーターフォール型モデルは、一般的であり、確実なた

(11)

V

字型モデル

V

字型モデルのイメージ

の構造

要件定義

外部設計

内部設計

運用テスト (システムテスト)

製造

結合テスト

総合テスト 検証

検証

検証

品質の埋め込みプロセス 品質の確認・検証プロセス

21

ソフトウェアの品質を確保する手段

要求 要求 要求 要求 定義書 定義書 定義書 定義書

外部 外部 外部 外部 設計書 設計書設計書 設計書

単体テスト 単体テスト 単体テスト 単体テスト 報告書 報告書 報告書 報告書

結合テスト 結合テスト結合テスト 結合テスト 報告書 報告書 報告書 報告書

総合テスト 総合テスト 総合テスト 総合テスト 報告書 報告書 報告書 報告書

要求定義 外部設計 内部設計 製造 結合テスト 総合テスト

内部 内部内部 内部 設計書 設計書 設計書

設計書 プログラムプログラムプログラムプログラム

単体テスト 単体テスト 単体テスト 単体テスト 計画書 計画書計画書

計画書 結合テスト結合テスト結合テスト結合テスト 計画書 計画書 計画書 計画書

総合テスト 総合テスト 総合テスト 総合テスト 計画書 計画書 計画書 計画書

定義書 定義書 定義書 定義書 レビュー レビュー レビュー レビュー

設計書 設計書 設計書 設計書 レビュー レビュー レビュー レビュー

単体テスト 単体テスト単体テスト 単体テスト

設計書 設計書 設計書 設計書 レビュー レビュー レビュー レビュー

結合テスト 結合テスト 結合テスト

結合テスト 総合テスト総合テスト総合テスト総合テスト

ソフトウェアの品質を確保する手段は、

●作成された定義書、設計書に対しては様々な観点からの自己レビュー、 第三者を含めたレビュー会議によるレビューである。

●作成されたプログラムに対しては、設計書から別途作成されたテスト計画 (テスト項目)によるテストである。

顧客 要求

成果物成果物成果物成果物

品質保証品質保証品質保証品質保証

(12)

V

字型モデルの問題点

• V字型モデルの問題点は、初めてのシステム化や、非常に

複雑なシステムの場合、要件定義フェーズですべての要 件を洗い出すのが難しい。

• V字型モデルのテスト・フェーズは、工程の後半に設定され

るため、要件定義フェーズや外部設計フェーズなどの上流 工程に欠陥があった場合、プロジェクトの終盤まで発見で きないことが多い。

• 工程の終盤で、要件漏れや欠陥が発見された場合は、大

幅な作業の手戻り(前のフェーズに戻ること)が必要になる。

• 作業の「手戻りコスト」は極めて大きなものになり、最悪の

場合はシステム開発自体が完成せず、中止に至る場合も まれではない。

23

(13)

プロトタイピング

• 要求漏れ対策として、ウォーターフォール型の上流工程にプロ

トタイピングを組み合わせる

– プロタイピングは、試作品(プロトタイプ)を作成し、実際に利用者に使用

させその結果から、利用者が気が付かなかった要求を獲得する手法

– 利用者を交えながら要件を早期に把握・確定し,要件の漏れや誤解を防

ぐことができる

• プロトタイプの種類

– プロトタイプには、作成したプロトタイプを試用版のみで利用しレビュー後

に捨てるタイプ

– プロトタイプを実際のシステムに実装するタイプ

– 帳票やユーザー・インタフェースなど,ユーザーが目で見たり実際に使っ

て確認できるプロトタイプ

– データベースの接続部分や共通機能のパフォーマンスなどのシステム

の重要部分を評価するためのプロトタイプ

25

スパイラル型モデル

• 「スパイラル型モデル」は、ウォーターフォール型の問題点を

解決するために登場した開発プロセスモデル

– 問題点とは、要件定義フェーズで要件を洗い出すのが難しく、プロ

ジェクト終盤になって欠陥が明らかになることが多いこと

– 1988年にB.W.ベームによって提唱された開発プロセス

• スパイラル型は、「計画」、「要件定義」、「設計」の各フェーズ

が1つのサイクルに相当する

– 各サイクルで,目標設定→分析・開発(プロトタイピング)→検証→次

段階の計画という手順を実施する

– 上流工程でプロトタイピングを実施・検証することで,要件や品質のリ

スクを減らす効果がある

– ウォーターフォール型の上流工程でプロトタイピングを活用するアプ

ローチを体系化した開発プロセス

(14)

スパイラル型モデルの構造

27

RAD

Rapid Application Development

• RADは、いくつかの開発アプローチを組み合わせ、短期間かつ低コストで

のシステム開発を実現する。

– 1991年にJ.マーチンによって提唱された。

– ウォーターフォール型の「短期開発に対応できない」という不満を解消するた

めに登場。

– 80年代後半から小規模なクライアント/サーバー型のシステム開発案件が

増え,同時に高い生産性を持った開発ツールが登場した。

• RADのアプローチ

– システムを小さな単位に分割し,それを3カ月などの短期間(タイムボックス)

で順番に開発していく。

– 第4世代言語(4GL)や特定用途向けの高生産性開発ツールを用いてプロトタ

イピングを積極的に活用する。

– エンドユーザーのプロジェクトへの十分な参画を必須とする。

(15)

追加型・反復型モデル

オブジェクト指向やコンポーネント技術の普及により、

それに適した開発プロセスが登場する。

追加型(インクリメンタル型)モデル

– システム全体をいくつかの部分(サブシステムなど)に分割

し,それを順次追加開発する。

追加型モデルの手法

– システムの基盤部分や共通機能をまず開発し、順次優先

順位や開発上のリスクの高い機能から開発を進める。

– 追加する機能ごとに、開発とテストを繰り返すため、常に

稼働状態の本番システムとなる。

– リスクを早めに検証でき、完成した機能から順次利用者が

使用できるので、短期にシステムを利用したいユーザに歓

迎される。

29

追加型・反復型モデル

反復型(イタレィティブ型)モデル

分割し

た部分ごとに開発・テストを繰り返してシステ

ムを成長させる。

分割した部分ごとに開発サイクルを繰り返し,修

正/改良を加えながらシステムを完成に近づける。

各サイクルごとに目標と達成基準を設定し、完了

時に達成基準の評価を実施。基準を満たしていれ

ば次の反復へ進む。

IBM

RUP

Rational Unified Process

)が代表的イタ

レィティブ型モデルである。

(16)

31

IBM

RUP

Rational Unified Process

)モデル

方向付け 推敲 作成 移行

○作業分野

・ビジネスモデリング

・要求 ・分析と設計 ・実装 ・テスト ・配置

・構成と変更管理

・プロジェクト管理 ・環境

繰り返し

追加型・反復型モデルのイメージ

(17)

追加型・反復型モデルの特徴

• 追加型・反復型モデルの特徴は,開発とテストを複数回に分けて

実施するため、システム開発の初期段階ですべての要件を洗い 出して仕様を確定・凍結する必要がない。

• システム開発途中の要件の追加や変更にも対応しやすい。

• リスクの高い新技術を利用する場合でも、開発とテストを繰り返し

検証することでリスクを低減できる。

• 要件の洗い出しを、先送りにしてよいわけではない。

• 要件はできる限り早期に洗い出し,それぞれの優先度やリスクを

検討して設計/コーディングに進む。

• 要件の早期確定が重要なのは、ウォーターフォール型モデルと同

様である。

33

アジャイル型モデルと

SOA

(18)

アジャイル型モデルとは

• 最近の登場した開発プロセスは、「アジャイル型」(俊敏な)モ

デルであり、多くの注目を集めている。

– 2002年ごろから,XP(eXtreme Programming)やFDD(Feature Driven

Development),スクラム(SCRUM)など開発プロセスが登場

• アジャイル型モデルは、開発プロセスとともに、シンプルな設

計,ユーザーと開発者あるいは開発者同士のコミュニケー ションの重視などの、テクニックやプラクティス(実践項目)も

含む。

– アジャイル型モデルの開発プロセスは、基本的に反復型のアプロー

チをとり、追加・反復型の変形モデルといえる。

– アジャイル型モデルの反復サイクルの長さは、1週間から最大でも3カ

月程度と短く、ユーザからのフィードバックの頻度を増やし,システム の仕様を確実にすることを目指している。

35

アジャイル型モデルの基本概念

1

アジャイル型モデルの特徴

– アジャイル型モデルでは、1週間から数週間などの短い

期間単位ごとに、完全に開発されたテスト済みの機能をリ リースする

• 機能とはシステム全体のごく小さな利用者が利用可能な部分で

ある

• アジャイル開発手法では、利用可能なシステムを早期に構築し、

継続的に改良を行う手法をとる

• 反対にウォーターフォール型モデルは、 、数か月から数年の長い

期間を単位として、大規模な開発とリリースが行われ、時間の経 過による利用者の要求の変化が大きな問題を起こすことが多い

– アジャイルソフトウェア開発規模

• アジャイル型モデルは、10人以下の優秀なエンジニアを集めた小

(19)

アジャイル型モデルの基本概念

アジャイルソフトウェア開発宣言

– 2001年に、アジャイルソフトウェア開発手法 の分野で有名な、

ケント・ベック、マーチン・ファウラーなど17人が、アメリカの

スノーバードで発表した宣言

– 彼らが別個に提唱していた開発手法の重要な部分を整理

統合することを議論し、「アジャイルソフトウェア開発宣言」

(Manifesto for Agile Software Development) をまとめた

37

クリティカルなシステム クリティカルでないシステム

従来型開発モデル アジャイル型開発モデル(WF)

経験がない開発者が多い 熟練した開発者が多い

開発者の数が多い 開発者の数が少ない

開発中に要件が変わらない 開発中に頻繁に要件が変わる

秩序を重視する組織 変化に意欲的に立ち向かう組織

アジャイルソフトウェア開発宣言

12

原則

顧客満足を最優先し、価値のあるソフトウェアを早く継

続的に提供する

要求の変更はたとえ開発の後期であっても歓迎し、変

化を味方につけることによって、顧客の競争力を引き

上げる

動くソフトウェアを、

2-3

週間から

2-3

ヶ月というできるだ

け短い時間間隔でリリースする

ビジネス側の人と開発者は、プロジェクトを通して日々

一緒に働かなければならない

意欲に満ちた人々を集めてプロジェクトを構成し、環境

と支援を与え仕事が無事終わるまで彼らを信頼する

情報を伝えるもっとも効率的で効果的な方法は、フェイ

ス・トゥ・フェイスで話をすることである

(20)

アジャイルソフトウェア開発宣言

12

原則

続き

動くソフトウェアこそが進捗の最も重要な尺度である

アジャイル・プロセスは持続可能な開発を促進し、一定

のペースを継続的に維持できるようにする

技術的卓越性と優れた設計に対する、不断の注意が

機敏さを高める

シンプルさ(ムダなく作れる量を最大限にすること)が

本質である

最良のアーキテクチャ・要求・設計は、自己組織的な

チームから生み出される

チームがもっと効率を高めることができるかを定期的

に振り返り、それに基づいて自分たちのやり方を最適

に調整する

39

アジャイル型開発手法の例 -

XP

• XP(Extreme Programming)はアジャイル型開発手法の一つ

で、1996年頃にケント・ベックらにより考案されたものである

– XPは実際の開発活動の内容を詳細に定義し、少人数の開発向

きモデル

• XPの開発チームが共有すべき4つの価値

– Communication (コミュニケーション)

• 顧客と開発者の、もしくは開発者間の円滑な対話

– Simplicity (シンプルさ)

• 必要最小限の設計しか行わない

– Feedback (フィードバック)

• 頻繁なテストによるfeedback)

– Courage (勇気)

• 大胆な設計変更に立ち向かう

• XPでは10個程度の活動手法を定義し、設計書の充実よりも

(21)

XP

の代表的活動

• 反復

– 開発期間を4週間以下の短期間に区切り、期間ごとに部分的な設計/実装/

テストを行ない、半完成システムのリリースを繰り返す

• テスト駆動型開発(Test Driven Development)

– プログラムをコーディングする前に、テストプログラムを作成し、プログラムの

コーディングは、テストをパスすることを目標とする

• ペアプログラミング

– 2人1組でプログラムを行ない、1人がプログラムを書き、他の1人はそれを確認

し検証する

• リファクタリング

– 外部から見た動作が変わらない範囲で、完成プログラムを効率化、洗練な改

善を行う

• プログラムコードの共同所有

– プログラムコードをプロジェクトチーム全員が断りなく修正できる

• 継続した結合

– 単体テストをパスするプログラムができる度に、毎回結合テストを行なう

• YAGNI(「You Aren‘t Going to Need It」)

– 今必要なことだけを行なう、すなわち必要な機能だけの簡潔な実装に止める

41

XP

の代表的活動 例

42

テスト駆動開発とリファクタリング

(22)

SOA

Service Oriented Architecture)

• SOAは開発モデルであるが、SOAというアーキテクチャーに基づい

て、様々なソフトウェアの体系が構築され、現実に運用されている インフラストラクチャーということができる

• SOAの概念は、サービス(ソフトウェア)の部品化である

– ソフトウェアをサービスという部品に分割し、それらを組み合わせてシ

ステムを構成する手法

– SOAは新しい概念ではなく、オブジェクト指向プログラミング、構造化

プログラミングなどの設計手法の延長である

サービスというソフトウェア部品の組み合わせにより

ソフトウェアを構築する手法

SOAとは

○独立して稼働する

○ビジネスプロセスを実行する

○WEBサービス(SOAP)で呼び出される

○粒度が粗い(大きな単位) ○実行時に組み合わされる

○ひとつのインスタンスで常駐し実行される ○WDSLでインターフェースが定義されている

○複数アプリケーションで利用可能である サービスとは

43

SOA

とデータベースの比較

データベース(DB)

データベース管理システム (DBMS)

アプリケーション プログラム A

アプリケーション プログラム B SQL

データ

SQL

データ

アプリケーション プログラム A

アプリケーション プログラム B

○データベースの場合 ○SOAの場合

インター

ネット

SOAサーバー

リクエスト リクエスト

(23)

SOA

の使い方

ー 天気予報を見る場合の例 -

WEBサイト(人間の場合) SOA(システムの場合)

相手 例:天気予報サイト 例:天気予報サイト

主体 消費者(人間) 検索プログラム

天気予報を見るシ

ナリオ

明日ある行楽地へ行くので、

天気を知りたい

明日ある行楽地へ行くので、天気

を知りたい(場所のIDは既知)

実際のやり取り ○ブラウザで天気予報サイ トのURLを入力し実行

ホームページのトップ が画面にでる

○見たい場所を指定し実行

その地域の天気情報

が画面に表示される ○天気を判断し、行くかやめ

るかを決定する

○WEBサービスの関数に天気予

報サイトのWEBサービスのURL

を設定する

・その際に行楽地のIDを設定

関数の実行結果に、その地 域の天気情報が戻ってくる ○情報を解析し、必要情報を抽

出する

○プログラムで行くべきかの判断

をし、画面等で人間にアドバイ スする

45

基本的に人間とWEBサイトとのやり取りは、WEBサービスの関数で実現できる

SOAの事例

旅行会社の予約シス テムが、クレジット会 社、ホテル、航空会社

各社のWEBサービス

を利用して顧客のブラ ウザからの依頼を処 理する例

この記述方法は

BPMN

(ビジネスプロセスモ デリング記法)という

Updating...

参照

Updating...

関連した話題 :