予想テスト問題(2)と(3)
------------過去問から--------------
（１）分析モデルは、ドメイン分析と要求分析で作成したモデルを活用して作成するが、
モデル間の関係を簡単な事例で説明せよ。
要求モデルでユースケース図を作成、ユースケースの一つ一つにアクティビティ図を作成。
分析モデルでは、アクティビティ図を元に分析レベルでのクラス図・コラボレーション図を作成。
設計モデルでは、分析レベルでのクラス図を元に、設計レベルのクラス図を作るため、ステートチャート図を作ったり、コラボレーション図を元にシーケンス図を作成したりする。
（２）ロバストネス分析に関して、その目的、入力モデル、手順を説明せよ。
ロバストネス分析とは：ロバスト(頑強)なシステム全体構造を得るオブジェクト指向分析手法
入力モデル：ユースケースモデル、概念モデル
目的：ユースケースの妥当性の検討/洗練、概念モデルの洗練、設計モデルの元を導出
手順： 1. アクタから該当するユースケースのインターフェースとしてバウンダリを作成
2. 該当するユースケースに関与するエンティティを概念モデルから識別、あるいは新規に作成
3. バウンダリとエンティティを繋ぐコントロールの作成
（３）要求工学が必要な理由を一つ挙げ、例を用いて説明しなさい。
＞理由：納期の遅れやコスト超過を抑えることができるから
例えば、顧客からある大きなソフトウェアを作って欲しいと言われたら、ベンダー側は顧客の要求仕様を満たす
ソフトウェアを制作していかなくてはならない。しかし、顧客の要求する仕様は必ずしもその状況に適したソフトウェアで
あるとは限らないし、将来的にスムーズに修正・変更を行えるソフトウェアであるとも限らない。結果、顧客の要求仕様が
制作途中で変わる可能性が高まり、それが納期の遅れやコスト超過に繋がる。このため、要求工学に基づいて"ユーザは
何が目的なのか"という部分を適切に定義する必要がある。
（４）抽象化、カプセル化、情報隠蔽のそれぞれ意味と、3者の間の関係を説明せよ。
抽象化：同じものや、共通点のあるものを同じグループに分けること。 http://www2.ocn.ne.jp/~countabl/ti/abstract1.html
カプセル化：オブジェクトのインターフェイスだけを公開し、そのインターフェイスのみが内部状態の操作を行えるようにしたもの。 http://www.curiocube.com/mikata/oop/p2_ch02_encapsulation.php
情報隠蔽：オブジェクトの持っている属性と操作を外部から隠すこと。 http://634.ayumu-baby.com/oo/concealment.html
3者間の関係：情報隠蔽とは、カプセル化を抽象化したものである。
（５）境界値分析とはどのようなテスト手法であるかについて、例を用いて説明せよ。
ブラックボックステストの一つで、同じ振る舞いをするであろう範囲を定め、その範囲の端の値をテストデータとして選ぶテスト手法。
例えば、郵便物の重さから郵便料金を計算するプログラムで、郵便物の重さが0g以下の場合にエラーを返し、25g未満の場合に80円、
25g以上50g未満の場合を90円、50g以上の場合を"定形外"と返すプログラムを考える。このプログラムの場合、境界値分析では、
テストデータとして、0g, 1g, 24g, 25g, 49g, 50gを選ぶことになる。
（６）修正保守と適応保守についてそれぞれ説明し、それらの違いについて述べよ。
修正保守とは誤りが発見された時に修正を行う作用を意味し、適応保守とは利用環境や動作環境に追従するために
変更する作業を意味する。これらの保守の違いは、能動的な保守であるか受動的な保守であるかの違いである。
修正保守では、誤りが発見されるかどうかで修正するかどうかが決まるので受身的な保守であるといえる。一方で、
適応保守では、変化する環境においてもソフトウェアを使用出来るように修正するため、能動的な保守であるといえる。
（７）シーケンス図と活性区間
シーケンス図とは、複数インスタンス間の一連のメッセージの流れを時系列にそって表したダイアクラムである。
活性区間とは、シーケンス図のモデル要素の一つで、活性区間で表されたオブジェクトに制御が移っていることを示す。
（８）ステークホルダー
あるモノに関わる利害関係者のことを指す。ソフトウェア工学においてはソフトウェア要求に関わる登場人物のことで、
主に、ソフトウェアの実際に使うユーザ、ソフトウェアの発注者である顧客、受注者であるソフトウェア開発者のことを指す。
（９）UMLにおけるステレオタイプ
既存のモデル要素を用いて、新しいモデル要素定義するもの。ステレオタイプは、UMLの図中では一般的に
<<ステレオタイプ名>>で示されるが、アイコンのような特殊な図形表示を持つことも出来る。
（10）コンポジション
集約に関する一つの形態で、集約より「全体-部分」の関係が強い。具体的な特徴としては、部分側のライフタイムが
全体側のライフタイムに依存する、関係の変更が出来ない、全体側の多重度は1といった特徴がある。
（11）プログラムスライシング
着目する変数に影響を与える一部のコードのみを、プログラムから抽出する技術のこと。
デバッグ、テスト、再利用、理解支援、リファクタリングなどのソフトウェア開発・保守に利用される有用な手法である。
(12) 良いソフトウェアの要件とは
良いモデルに基づいてシステム開発が行われ、安定した開発工程で制作されたソフトウェア。良いソフトウェアは、要求仕様を
満たすだけでなく、仕様変更があっても容易に修正・変更が出来、またテストも行い易い。
(13) UML 1.5 で定義されている9種類の図の中から、3種類を取り上げて、各図の役割を説明せよ
9種類の図:クラス図, オブジェクト図, ユースケース図, シーケンス図, コラボレーション図,
ステートチャート図, アクティビティ図, コンポーネント図, 配置図
構造図 クラス図： モデルの組み立て部品の集合のこと。クラスと関係によって、クラスの構造とクラス間の関係を表現する
構造図 オブジェクト図： システムのある時点でのスナップショット
振る舞い図 ユースケース図： システムのコンテキストと外部機能の設定
振る舞い図 相互作用図 シーケンス図： 相互作用するオブジェクトの時間順序系列。オブジェクトの集団メッセージ送信の時系列表現。
振る舞い図 相互作用図 コラボレーション図： オブジェクト集団における相互作用の直接表現やオブジェクト集団の接続トポロジーとメッセージ、スレッドの順序などを表現する
振る舞い図 ステートチャート図： 1つのオブジェクトの生成から消滅までの状態遷移。あるクラスに属するオブジェクトの「ライフサイクル表現」を提供する。
振る舞い図 アクティビティ図： 1つのインタラクション全体における手続きの制御フロー。状態図の相対表現としてワークフローに焦点を当てる図
実装図 コンポーネント図： ソフトウェア-ユニット間の依存関係を示すもので、ソフトウェアモジュールの構成やバージョン管理も表現することができる
実装図 配置図： オブジェクトやパッケージ、ファイルなどを実際のプラットフォームやネットワークノード上のどこに配置するのか、
さらにはどのプロセス上で実行するのか、といった物理的な視点でシステム構成を表現する
http://www.atmarkit.co.jp/im/carc/serial/dstylefaq/uml/uml1_2/uml1_2.html
(14) なぜ要求工学が必要なのか
理由：納期の遅れやコスト超過を抑えることができるから
例えば、顧客からある大きなソフトウェアを作って欲しいと言われたら、ベンダー側は顧客の要求仕様を満たす
ソフトウェアを制作していかなくてはならない。しかし、顧客の要求する仕様は必ずしもその状況に適したソフトウェアで
あるとは限らないし、将来的にスムーズに修正・変更を行えるソフトウェアであるとも限らない。結果、顧客の要求仕様が
制作途中で変わる可能性が高まり、それが納期の遅れやコスト超過に繋がる。このため、要求工学に基づいて"ユーザは
何が目的なのか"という部分を適切に定義する必要がある。
(15) トップダウンテストとボトムアップテスト
トップダウンテスト：上位モジュールから下位モジュールに向かって、スタブを使いながらテストするやり方。
ボトムアップテスト：下位モジュールから上位モジュールに向かって、スタブとドライバを使いながらテストするやり方。
(16) ソフトウェア保守に関してハードウェア保守と比較せよ
ソフトウェア保守：
開発のすべての段階の知識をもったCustomer Engineerによって、ソフトウェア開発段階で作成されたすべての成果を
維持・管理する作業。具体的な作業内容として、運用段階で検出されたエラーの修正や新機能の追加、既存機能の変更を
行い、納入後の開発ソフトウェアを新しい環境へ適合させていく。
ソフトウェアは経年劣化することがなく、導入後の修正も簡単で、量産・流通にかかるコストも低いので、
経年劣化して、導入後の修正がほぼ不可能で、量産・流通にコストのかかるハードウェアとは要求する内容が大きく異なる。
具体的には、ハードウェア保守は、機能や性能を維持するように要求されるが、ソフトウェア保守はそれだけでなく、
機能拡張、性能改善、環境適合することも求められる。
--------------------------------------------------------------------------
以下、オリジナル問題(予想)
(17)スタブとドライバの違い
スタブ：上位モジュールのテストのために用意された、下位モジュールの役割をシミュレートするテスト用モジュールのこと。。
テストされる上位モジュールから呼び出されたら、引数などの正当性をチェックし、適当な処理結果をテストモジュールへ返す。
ドライバ：下位モジュールをテストするときに上位モジュールの役割をシミュレートするテスト用モジュールのこと。
必要な引数をセットし、テストされる下位モジュールを呼び出す。このとき、テストされる下位モジュールの
処理結果を表示したり、関連するデータの反応をシミュレートしたり、実行のパスを追跡したりする。
http://roots55.tripod.com/4syou.htm
(18)見積り方法について
(18-1)デルファイ法
1見積もり者複数人が見積もりを行い、調整者が調整する。それを数回繰り返し、最終的な見積もりを出す。
非常に正確な結果を出すことができ、どんな規模の製品に対応できる一方で、時間がかかり、共通の偏りが入りやすく、
少数のエキスパートに依存してしまうという欠点もアル。
(18-2)ファジー理論
製品規模の履歴データを規模の範囲に分割→開発予定の製品を以前の製品と比較→規模を決定
使いやすく、特別なツールや訓練もいらないなどのメリット。数多くのデータが必要、
プログラムが新しい場合には役立たない、大雑把な規模の値を提供するだけ、
履歴データより大きかったり小さいと役に立たないなどのデメリット。
(18-3)ファンクションポイント法
アプリケーション中の機能のタイプ毎に数を決定→各機能の複雑さと規模を決定→
ファンクションポイントの合計を計算→ファンクションポイント当りの開発コストについての履歴データを見積もりに使う→
ファンクションポイントに比率をかけて見積もり値を出す。
最も初期の要求フェイズに使える、プログラミング言語・製品設計・開発形態によらない、
数多くの履歴データがある、文書が整っているのメリット。
履歴データがないと見積もりのスキルの改善が難しい、プログラミング言語・製品設計・開発形態の違いを反映しない、
既存製品に対してファンクションポイントの項目を直接カウントできないのデメリット。
(18-4)ウォータフォールモデル
要求分析、設計、実現、テスト、運用・保守の順番でシステムを開発。順番を守って開発する必要あり。利点として、
・全ての工程が順次に進められる
・全体の見通しがつきやすい
・スケジュールの決定や資源配分が計画通りに行われる
・工程が理解しやすい
・大規模のシステム開発に向いている
欠点として、
開発工程の初期の段階で要求仕様を確定することは現実的に難しい
ユーザインタフェースの要求はシステムが完成した時点で無ければ確立できない
プロトタイプモデル
開発の早い段階でシステムの試作品を作り、ユーザに使ってもらうことでユーザの要求を明確にするモデル。小規模開発向け
(18-5)スパイラルモデル
プロトタイプモデルとウォータフォールモデルの利点を抽出したモデル
(22-23)シーケンス図とコラボレーション図の違いについて
・シーケンス図
複数インスタンス間の一連のメッセージの流れを時系列に沿って表したダイヤグラム。
時間の経過の中で、対象システムがどのように動くのかという動的な振る舞いを表現する。
相互作用図には、シーケンス図、コラボレーション図の２タイプがある。
シーケンス図は、ある機能や振る舞いを表現するのに必要な各オブジェクト間のメッセージのやりとりを時間順に表現する。
・コラボレーション図
コラボレーション図とは相互作用図の一種で、オブジェクト間のメッセージ関係を表す物である。
シーケンス図と同じ情報を持っている。オブジェクト間の協調を、オブジェクト間の接続関係に着目して、
メッセージやデータの流れを表現する。動的。シーケンス図とコラボレーション図の違いは出るかもしれない。
勘だけど。シーケンス図は時間の流れに沿ったメッセージの流れを表現。
コラボレーション図はオブジェクト構造の中での制御フローを表現。
(24)多重度
関連で結ばれた片側のクラスの１つのインスタンスに関連する、もう片側のクラスのインスタンスの数。
(25)集約とコンポジションの違い
全体とその部分に結ばれる関連の特殊な形式。全体は部分の集まりからなる。
コンポジションとは違い、全体の方が消滅しても、部分側は消滅せずに残る。
(26)ステートチャート図
状態遷移図のこと。クラスの状態がイベントによって遷移することを表すダイヤグラム。
各クラスに対して記述する。１つのオブジェクトに着目した、その状態の変化を表す。
外部からの刺激に対する、そのオブジェクトの反応を表す。
(27)ガード条件
イベントを受理して状態を遷移させるために真となっていなくてはいけない論理式のこと。
(28)ＵＭＬを使う理由
綺麗な図を書ける・誤った図を書くと注意される・自動的にサイズなどを調整・データを再利用、２次利用しやすいなど
(29)プロセス図
業務活動の流れと、各工程の入力と出力を明らかにする。
(30)ドメイン分析
顧客とのスムーズな対話の実現のために、対象となる世界（ドメイン）の正確な理解を目的として、
業務状況を概念モデル(対象業務の世界を構成する本質的かつ注目する概念と概念間の関係を表すモデル)として表しておく工程。
(31)代替系列
基本系列で例外が発生した場合の処理手順
(32)事前条件と事後条件
事前はユースケース実行前に満たしておく必要がある条件のこと
事後はユースケース実行後に満たさなければならない条件のこと
(33)オブジェクト指向開発における設計モデル
動的側面はシーケンス図とステートチャート図(上参考)。静的側面はクラス図。
システムを実現するためん必要なクラス間の関係を表現
(34)４つの保守(修正・適応・改善・予防)とその意味
修正保守は、誤りを発見した場合にそれを修正する作業である。
適応保守は、利用環境や動作環境の変化に追従するための変更作業である。OSの更新や対象領域・対象組織が変化した場合などに行う。
改善保守は、ソフトウェアのある側面を拡張したり、向上させたりする変更作業のことである。将来の機能拡張や機能変更を容易にしたり、ソフトウェアの管理、分かりやすいソフトウェアにしたりする。
予防保守は、故障を未然に防ぐという観点で、潜在的な誤りを除去しておく作業である。障害が起こってから誤りを修正するのでは無く、未然に障害を防ぐ。改善保守に類似。
(35)６つの保守技法について
(35-1)構成管理
構成管理とは、過去に実施された変更を管理する作業のこと。
バージョン(利用者の要求を満たす特定の構成)とリリース(以前のソフトウェアを修正、あるいは改善したもの)を管理する。
(35-2)影響分析
影響分析とは、保守による変更あるいは追加による影響が及ぶ範囲を把握する作業である。
影響範囲を変更前に解析し、保守に必要な資源や工数を見積もる作業でもある。
(35-3)回帰テスト
回帰テストとは、以前のソフトウェアで動作していた機能が、
新規あるいは修正後のソフトウェアで正常に動作するかどうかの検査、
もしくは未変更部分がもとの通りに正常に動作するかどうかを確認する。
(35-4)ソフトウェア視覚化
ソフトウェア視覚化は、ソフトウェアに関わるさまざまな情報を人間が理解しやすい形式で表現すること。
(35-5)ソフトウェアエンジニアリング
ソフトウェアエンジニアリングとは、既存のソフトウェアを若返らせる作業のこと。
(35-6)プログラム理解
プログラム理解とは、保守作業に必要。
プログラム理解の支援に、コーティング規約(変数や関数の名前付けを工夫、字下げなど)、
制御フロー解析(制御フローを解析することで、プログラムに現れる分岐や繰り返しを明確化にする)、
データフロー解析(プログラム中のデータの定義と参照の関係を解析することで、あるデータがプログラムのどの部分に関与するかが明確になる)、
依存解析(制御フロー解析とデータフロー解析の結果を用いることでプログラム内部に潜在する依存関係を抽出する)、
プログラムスライシング(上参考)、
クリシェ及びイデオム(ある目的を実現するためにプログラマが頻繁に記述するスタイルや記述パターン)がある。
(36)受け入れテストについて
(36-1)機能テスト 要求されている機能を果たしているか
(36-2)過負荷テスト 短時間に、その制限まで負荷をかけたときのシステムを評価
(36-3)容量テスト システムで非常に大きいデータ量を扱う
(36-4)構成テスト 要求で仕様化された、いろいろなソフトウェアやハードウェアの構成を分析する
(36-5)互換性テスト インターフェース機能が要求通りに実行できることを確認
(36-6)回帰テスト 新しいシステムの性能が少なくとも古いものよりは良いことを保証する
(36-7)機密性テスト セキュリティの要求が達成されているか
(36-8)タイミングテスト ユーザに応答する時間や機能を実行する時間に言及している要求を評価する
(36-9)保守テスト 診断用ツールが存在し、それらが正しく機能するかどうか
(36-10)文書化テスト 必要とされる文書を記述したことを保証する
(36-11)ヒューマンファクタテスト ユーザインタフェースを扱っている要求を調査する
(37)動的テストと静的テストの違いについて
動的は実行用の入力データを用意し、プログラムを実行し結果を検証。使われたデータについては結果確実だが、使われていないデータには不明
静的はプログラムを実行せず表現形式からテスト。特定の実行パスに依存しないが、実際にどう使われているか分からない
(38)インターフェースパートと実装パートの違いについて説明しなさい。
インターフェースパートは、コンポーネントが持つ機能性を定義し、コンポーネントの使用方法の仕様を定めた部分。
実装パートは、コンポーネントが持つ機能性に対する実コードを含む部分。コンポーネントのクライアントは実装の詳細を知る必要が無いので分離を行う。
(39)なぜソフトウェアアーキテクチャが重要か説明しなさい。
ソフトウェアアーキテクチャの説明によって、システム開発の関係者全員のコミュニケーションを可能にすることが出来る。
またアーキテクチャは早い段階での設計上の決定を明らかにすることができるから。
(40)デザインパターンとは何か
オブジェクト指向システムにおいて繰り返し発生する問題を対象として、
・設計の観点からの解決策と、その得失を記述
・解決策はクラスとオブジェクトとの組み合わせで表現
・実装上のヒントも与える
・解決策はカスタマイズされ実装される
(41)構造化設計手法とオブジェクト指向設計手法の違いについて説明しなさい。
構造化設計手法は、機能中心のシステム分割でトップダウン方式の階層化。仕様変更時に機能を変化させやすい。インターフェース重視。
オブジェクト指向設計手法は、モノ中心のシステム分割でボトムアップ方式のシステム構築
(42)リファクタリングの意味と、その作業手順について説明しなさい。
・リファクタリングとは
既存ソフトウェアの設計の理解性や変更容易性を向上させることを目的とした上で、
外部から見た挙動(振舞い)を変えずに、ソフトウェアの内部構造を再構成すること。
大きな設計変更を一連の小さな変換により実現。将来のクラスやクラス間の関係を完全には予測不可能で、
保守作業や改良により設計が劣化するので、リファクタリングが必要。
・リファクタリング作業手順
1、コードのどの部分をリファクタリングするかを特定
2、どのリファクタリングを適用するか
3、挙動を保存するための条件を確認
4、リファクタリングを実際に適用
5、リファクタリングの効果を確認
(43)多層アーキテクチャの各層とその役割について説明しなさい
– ユーザインタフェース層: GUIなどによるユーザとの対話
– アプリケーション層: システム全体の流れの制御
– ドメイン層: 永続化するデータ、関係、核となるロジック
– データソース層: データベースなどによるデータの永続化
(44) 単体テストの基本戦略
• 具体的に誤りを見つけるためには以下が不可欠
– 何が合っていて、何が間違っているのかの元となる仕様
– 仕様の満足を具体的に確認するための入力と正しい出力(オ
ラクル=期待出力)から構成されるテストケース
– さらに、正しい出力を予想できる入力以外の入力も網羅したい
• 以下を網羅するようにテストケースを用意する
– オブジェクトの全コンストラクタ・メソッド: 同値クラス・境界値テ
スト+デシジョンテーブルテストなど
– オブジェクトのライフサイクル: 状態遷移テスト
– オブジェクト間の相互作用: デシジョンテーブルテストなど
– オブジェクトのコード全体: ホワイトボックステスト(条件網羅、
分岐網羅など)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
文書化された要求: 機能要求
• 欲しいシステム: 航空便座席予約システム
• 機能要求1: 航空便を登録する
– 管理者は、システムに、新しい航空便の路線(出発地、到着地)、日程(出発日時、到
着日時)、エコノミークラスの料金と座席数、ビジネスクラスの料金と座席数を入力し、
新規登録できる。
– 管理者は、登録済みの全ての航空便を閲覧できる。各航空便の表示項目は、出発地、
到着地、出発日時、到着日時、エコノミークラスの料金、エコノミークラスの座席数、ビ
到着地 出発日時 到着日時 ノミ クラ の料金 ノミ クラ の座席数 ビ
ジネスクラスの料金、ビジネスクラスの座席数とする。
• 機能要求2: 座席を検索する
– ユーザは、システムに、希望する路線(出発地、到着地)と日程(出発日時、到着日
時)を条件として入力できる。
– ユーザは、入力後、入力された路線と日程の全航空便について、座席の種類ごとに
空いている座席の一覧を閲覧できる。各座席の表示項目は、出発地、到着地、出発
日時、到着日時、座席の種類、値段とする。
• 機能要求3:
機能要求3 座席を予約する
– ユーザは、表示された座席の一覧から、システムに、座席を指定して予約できる。
– システムは、指定された座席を予約し、その予約日時を記録できる。その際に、指定
された座席の空席数を1つ減らす。
– システムが扱う座席には、エコノミークラスとビジネスクラスの2種類があり、それぞれ
値段が異なる。
– システムは、座席の位置を扱わない。
– ユーザは、予約後、予約された座席の料金を閲覧できる。
• ユースケース: 対象とするユースケースの名前
象 す 名前
• アクタ: ユースケースを起動するアクタの名前
• 目的: アクタまたはシステムの所有者にとっての目的
• 事前条件: ユースケースの実行前に、システムが満たしていなけれ
ばならない条件
• 事後条件: 事前条件が満たされた状況においてユースケースを実行
した後の、システムが満たしていなければならない条件
• 基本系列: アクタとシステムの、ステップ単位でのやり取り
• 代替系列: 基本系列中の特定のステップについて、特定の状況下に
おける代替的なやり取り
• 備考: 対象ユースケースに関係する補足事項の記述
• シナリオ: アクタとシステムの、具体的な関わりの様子の記述。ユー
スケースのテストケース(テスト条件)となる。
ユースケース名:本を貸し出す
アクタ:図書館職員
目的:アクタが本を利用者に貸し出して、その事実を記録する。
事前条件:貸し出しの事実が記録されていない。
事前条件 貸 出 事実が 録され な
事後条件:貸し出しの事実が記録され、示されている。
基本系列:
- 1. アクタがシステムにアクセスする。
- 2. システムは利用者と貸し出そうとする本の入力を促す。
- 3. アクタは利用者と本を入力する。
- 4. システムは利用者が貸し出し上限を越えていないことを確認
して,その本が貸し出された事実を記録し、アクタに示す。
代替系列:基本系列4. 利用者が貸し出しの上限を超えている場合は警告する。
代替系列:基本系列4 利用者が貸し出しの上限を超えている場合は警告する
備考: 貸し出しの事実は、「利用者・本・貸し出し日時」とする。
シナリオ:
(1) 図書館職員の山本太郎は、システムにアクセスした。
(2) 山本太郎は、 2005/3/30/10:30に、利用者として田中一郎、本として『ソフト
ウェ ア工学』の貸し出し依頼を受け付けて、それぞれの情報を入力した。
(3) 山本太郎は、貸し出し事実として「田中一郎・ 『ソフトウェア工学』・
2005/3/30/10:30」を確認した。
(45) ユースケース: 航空便を登録する
• アクタ: 管理者
• 目的: 管理者が、新しい航空便を登録する。
• 事前条件: (なし)
• 事後条件: アクタが入力した路線と日程の航空便が登録されている
アクタが入力した路線と日程の航空便が登録されている。
• 基本系列
• – 1. アクタは、システムに、航空便を登録する旨を示す。
– 2. システムは、アクタに、路線、日程、料金、座席数の入力を促す。
– 3. アクタは、システムに、新しい航空便の路線(出発地、到着地)と日程
(出発日時、到着日時)、エコノミークラスの料金と座席数、ビジネスクラ
スの料金と座席数を入力する。
– 4. システムは、入力された新しい航空便を登録する。
– 5. シ
システムは、アクタに、登録済みの全ての航空便を示す。表示項目
ムは クタに 登録済み 全 航空便を す 表 項目
は、出発地、到着地、出発日時、到着日時、エコノミークラスの料金、エ
コノミークラスの座席数、ビジネスクラスの料金、ビジネスクラスの座席
数とする。
・ 代替系列: (なし)
• 備考: (なし)
(46) ユースケース: 座席を検索する
• アクタ: ユーザ
• 目的: ユーザが、希望する路線と日程の全航空便について空き座席を検索する。
• 事前条件: (なし)
• 事後条件: アクタが入力した路線と日程の航空便の空いている座席の一覧が表
アクタが入力した路線と日程の航空便の空いている座席の 覧が表示されている。
・ 基本系列
– 1. アクタは、システムに、航空便を探す旨を示す。
– 2. システムは、アクタに、路線と日程の入力を促す。
– 3. アクタは、システムに、希望する路線(出発地、到着地)と出発日を条件として入力
する。
– 4. システムは、アクタに、入力された路線と日程の全航空便について、座席の種類
ごとに空いている座席の 覧を示す。表示項目は、出発地、到着地、出発日時、到
ごとに空いている座席の一覧を示す 表示項目は 出発地 到着地 出発日時 到
着日時、座席の種類、値段とする。
・ 代替系列
– 基本系列4. システムは、該当する空席のある航空便がない場合は、警告する。
・ 備考
– 座席の種類は、エコノミークラスとビジネスクラスの2つ。
– システムは、座席の位置を扱わない。
(47) ユースケース1「航空便を登録する」のシナリオ
– (1) 管理者の山本花子は、システムに、航空便を登録する旨を
示した。
– (2) 山本花子は、新しい航空便としてJAL001便の情報を入力し
た。JAL001便の情報として、路線: Narita発 Los Angels 着、日
程: 2005/06/01/09:00発2005/06/01/ 15:30着、エコノミークラス
50000円70席、ビジネスクラス120000円30席を入力した。
– (3) 山本花子は、入力後に、登録済みの全ての航空便として
JAL001便の情報を確認した。 JAL001便の情報として、路線:
Narita 発 Los Angeles 着、日程: 2005/06/01/09:00発2005/06/01/
15:30着、エコノミークラス50000円70席、ビジネスクラス120000円
30席を確認した。
(48)ユースケース2「座席を検索する」のシナリオ
– (1) ユーザの田中太郎は、システムに、航空便を探す旨を示した。
– (2) 田中太郎は、希望する路線と出発日を入力した。路線として、
Narita 発 Los Angeles 着を入力した。出発日として、 2005/06/01
を入力した。
– (3) 田中太郎は、入力後に、検索結果として以下の2つの空いて
いる座席を確認した。
• [1] Narita 発、Los Angeles 着、2005/06/01/09:00発、
2005/06/01/15:30着、エコノミークラス、50000円。
• [2] Narita 発、Los Angeles 着、2005/06/01/09:00発、
2005/06/01/15:30着、ビジネスクラス、120000円。
(49) 解答19: ユースケース記述「座席を予約する」
・ ユースケース: 座席を予約する
• アクタ: ユーザ
• 目的: ユーザが、希望する路線と日程の航空便の座席を予約する。
• 事前条件: アクタが希望する路線と日程の航空便の空き座席が示さ
れている。
・ 事後条件: アクタが指定した航空便の座席の空席数が1つ減少して
いる。予約日時が記録されている。予約された座席の料金が示され
ている。
・ 基本系列
– 1. アクタは、システムに、座席を指定する。
– 2. システムは、指定された座席を予約し、予約日時を記録する。その際
に、指定された座席の空席数を1つ減らす。
– 3. システムは、アクタに、予約された座席の料金を示す。
・ 代替系列: (なし)
• 備考: (なし)
(50) 解答20: シナリオ「座席を予約する」
• ユースケース3「座席を予約する」のシナリオ
– (1) ユーザの田中太郎は、以下の2つの空いている座席を確認し
た状況において、座席[1]「Narita 発、Los Angeles 着、
2005/06/01/09:00発、2005/06/01/15:30着、エコノミークラス、
50000円」を指定した。
50000円」を指定した
• [1] Narita 発、Los Angeles 着、2005/06/01/09:00発、
2005/06/01/15:30着、エコノミークラス、50000円。
• [2] Narita 発、Los Angeles 着、2005/06/01/09:00発、
2005/06/01/15:30着、ビジネスクラス、120000円。
– (2) 田中太郎は、指定して予約された座席の料金5000円を確認
した。
ドメイン分析
– 顧客とのスムーズな対話の実現のために、
– 対象とする世界(ドメイン)の正確な理解を目的として、
– 業務状況を概念モデルとして表しておく工程
システム分析の手順
(1) 要求モデル中の各ユースケースの機能(詳細はアクティビティ図を参照)
•
を実現する様子を表すコラボレーション図をそれぞれ以下のように作成する
– (1-1) コラボレーション図を新規作成する
– (1-2) 必要なクラスのオブジェクトをコラボレーション図に追加する
– (1-3) 対応するユースケースの機能を実現するために必要なオブジェクト間の
メッセージ通信(相互作用)を加える
(2) 全
全コラボレーション図を束ねてクラス図を作成する
ボ を束ね ク を作成する
•
(3) 各メッセージ通信に対応する操作を各クラスに加える
•
(1-1) 全体のアーキテクチャ設計
• ソフトウェアアーキテクチャとは
– ソフトウェアシステムの構成要素と、それらの間の関係を示すもの
– ソフトウェアシステム全体がどのように組み立てられるか、あるいは、構
成要素がどのように協調動作するのかを、大局的に理解可能なモデル
• アーキテクチャの効果
– ソフトウェアアーキテクチャの説明は、システム開発の関係者全員のコ
フトウ アア キテクチ の説明は システム開発の関係者全員の
ミュニケーションを可能に
– アーキテクチャは、早い段階での設計上の決定を明らかにする
• アーキテクチャの必要性
– ソフトウェアシステムの大規模化/複雑化に伴い、アーキテクチャを途
中で変更することが困難
– ソフトウェア開発技術ライフサイクルの短縮化に伴い、その時点での最
新 開発技術を用
新の開発技術を用いる必要性
必要性
– 非機能要求(信頼性/性能/拡張性などの向上)の増大
分割統治: 複雑な全体問題を、小さな部分問題の集合に
分割し、個々の部分問題の解を集めて全体問題の解を
得る
• モジュール化: ソフトウェア全体を、一枚岩ではなく、幾つ
かの部品から構成されるように分析・設計する
• 効果
– 問題の切り分け、部分単位の開発
– 問題や影響の局所化
関心の分離
• ソフトウェアシステムにおいて、異なる責務
や無関係な責務は、たとえば、異なるコン
ポーネントに割り付けるなどして、分離され
るべき
0 件のコメント:
コメントを投稿