Please enable JavaScript.
Coggle requires JavaScript to display documents.
ソフトウェア工学Ⅰ - Coggle Diagram
ソフトウェア工学Ⅰ
ユースケースモデリング
概要
ユーザーがシステムと対話する方法と、システムがどう反応するかについて記述されたユースケースを作成
ユースケースモデリングを通して、ユースケース図とユースケース記述を作成
システムの動作の90%を説明する基本コース
何か悪いことが起こった場合やユーザーがまれにしか使わない機能を使用した場合の動作を説明する代替コース
実施前にすること
ドメインモデルを作る
ガイドライン
1.２段階ルールに従う
ユースケース記述は基本コースと代替コースそれぞれ文章で記述
２段落に収まるように、複数のユースケースに分割すべき
2.ユースケース図を使ってアクタとユースケースを整理する
3.ユースケースは叙述的に書く
先の見通しが立つように言葉を使う
4.イベントとその応答の流れをユースケース記述に書く
5.紙芝居やGUIプロトタイプ、画面のモックアップを使う
6.ユースケースは実行時の振舞いの仕様であることを忘れないようにする
ICONIXプロセスではユースケースが設計を駆動する
7.オブジェクトモデルの言葉を使ってユースケース記述を書く
8.「名詞（主語）-名詞（目的語）-動詞」という文の構造に従ってユースケース記述を書く
9,ドメインクラスの名前を使う
10.バウンダリクラスの名前を使う
実施例
1.パッケージを用いてユースケースを整理する
2.ユースケース記述に基本コースを書き、洗練させる
3.代替コースを洗い出す
ICONIXプロセス
概要
大きく動的なワークフローと静的なワークフローに分かれており、両者を行き来し、かつ、繰り返して進める
ユースケースとコードの間に存在する領域にフォーカスした最小限かつ効率的なアプローチ
小さなユースケース群に対して、単一のイテレーションではプロセス全体を実施
アジャイルプロジェクトと親和性が高い
作成されるモデル
ドメインモデル
プロジェクトで実際に使われる全ての単語を収録した用語集
単語間の関係がグラフィカルに表現されることが多い
ドメインモデリング
ガイドライン
現実世界における問題領域のオブジェクトに焦点を合わせる
オブジェクト同士の関係を表現するため、汎化関係、集約関係を利用
最初のドメインモデリングにかける時間は２時間
問題領域中の主要な概念を中心にクラスを構成
ドメインモデルをデータモデルと勘違いしない
オブジェクトとデータベースのテーブルとを混同しない
ドメインモデルをプロジェクトの用語集として使う
名前があいまいになることをさけるために、ユースケースを書く前にドメインモデルの図を作る
最終的なクラス図が、ドメインモデルと正確に合致することを期待してはいけないあ、この２つは何らかの形で相似の関係にある
ドメインモデルには、画面やその他GUI固有の部品クラスを配置しない
作り方の例
1.要求から名詞と名詞句を抽出
2.抽出した名詞と名詞句のリストを整理
3.集約の関係を使ってクラス図を作成
4.クラス図を整理
5.汎化関係を作成
ロバストネス図
クラス図とアクティビティ図の中間にあたるハイブリットな図
ユースケースに示された振舞いを図式化したもの
参加するクラスとソフトウェアの振舞いの両方を示す
流れ
1.要求（「マイルストーン１：要求レビュー」を含む）
1回の分析において1回のみ実施
手順
1.機能要求の定義
2.ドメインモデリング実施
3,振舞い要求定義
4.マイルストーン１として要求レビュー実施
2.分析/予備レビュー
手順
1.ロバストネス分析を実施
ロバストネス図作成
ユースケース記述修正
2.ユースケースとロバストネス図を書きつつ、ドメインモデルを更新
3.ユースケースを動かすために必要な、全ての論理的なソフトウェア機能（コントローラ）に名前をつける
4.フェーズ１の手順3で作ったユースケースを書き直す
3.マイルストーン２：予備設計レビュー(PDR)
ロバストネス図、ドメインモデル、ユースケース記述の整合性がとれていることを確認
4.詳細設計
手順
1.ユースケースごとに1枚ずつシーケンス図を作成
2.シーケンス図を作りながらドメインモデルを更新して、ドメインオブジェクトに操作を追加
3.静的モデルの整理
5,マイルストーン３：詳細設計レビュー(CDR)
詳細設計によって示される方法が、要求によって示される目的に適合していることを保証
設計の品質を確認
シーケンス図上のメッセージの一貫性をチェック、設計における論理的な飛躍を取り除く
6.実装
手順
1.コードと単体テストを記述
2.結合テストとシナリオテストを実施（基本コースと代替コースをテストするため、ユースケースに基づいた結合テストを行う）
3.開発の次のラウンドに向けた準備として、コードレビューとモデルの更新を行う
ロバストネス分析
ユースケースとオブジェクトの関連付けを行い、分析と設計のギャップを埋める手法
ロバストネス図
ステレオタイプアイコン
バウンダリオブジェクト
システムとシステムの外側の世界とのインタフェース
エンティティオブジェクト
ドメインモデル上のクラス
コントローラ
バウンダリオブジェクトとエンティティオブジェクトを結ぶ
詳細設計のクラス図ではメソッドになる
作成時のルール
アクタとバウンダリオブジェクトは関係を持つことができる
バウンダリオブジェクトとコントローラは関係を持つことができる
コントローラと他のコントローラは関係を持つことができる
コントローラとエンティティオブジェクトは関係を持つことができる
アクタとコントローラやエンティティオブジェクトは関係を持てない
バウンダリオブジェクトとエンティティオブジェクトは関係を持てない
エンティティオブジェクトと他のエンティティオブジェクトは関係を持てない
バウンダリオブジェクトと他のバウンダリオブジェクトは関係を持てない
ガイドライン
1.ユースケース記述をロバストネス図に直接貼り付ける
2.ドメインモデルからエンティティクラスを取り出し、不足しているエンティティクラスがあればドメインモデルに追加する
3.ロバストネス図の作成中にも、ユースケース記述を書きお成して明確にする
4.画面単位でバウンダリオブジェクトを作成し、明確な画面名を付ける
5.コントローラは通常、論理的なソフトウェア機能であることを忘れない
6.ロバストネス図上の矢印の方向について気にしてはいけない
7.呼び出し元のユースケースをロバストネス図上に置く
8.ロバストネス図はユースケースに対する予備的な概念設計を示す
9.ロバストネス図上のオブジェクトは詳細設計で姿を変える
10.ロバストネス図はユースケースの「オブジェクトの絵」であることを忘れない
ソフトウェア工学
情報システム
ソフトウェア
特徴
規模と複雑さ
変化の激しさ
多種多様さ
開発
問題点
管理や組織
変化
上流工程
プロセス
要求定義
設計
基本設計
詳細設計
実現技術の決定
設計の確認
実装
実行可能なソフトウェアの定義
ソフトウェアの構築
実行環境の設定と配置
デバッグ
テスト
保守
プロセスモデル
ウォーターフォールモデル
原則的にフェーズの重なりや繰り返しを行わない
課題
変更への対応
開発上のリスクへの対応
V字モデル
インクリメンタルプロセスモデル
各フェーズを重なりを持たせながら繰り返して、システムを徐々に増加的に完成させていく
進化型プロセスモデル
プロトタイピング
スパイラルモデル
アジャイル開発
スクラム
エクストリームプログラミング
ソフトウェアの作成と利用に関連した概念を科学的に抽出・体系化し、正しいソフトウェアを計画的かつ効率的に作成・利用するための理論と、実践的技術
ソフトウェアモデリング
有用性
基本的な視点の記述方法の提供
表現の規模や複雑さの軽減
性格な表現の提供
Unified Modeling Language(UML)
モデリング言語
ダイアグラム（モデルを可視化する図）
静的
クラス図
クラスにより構造を表す
オブジェクト図
オブジェクトにより構造を表す
振舞い
ユースケース図
システムがどのような利用のされ方をするかを記述するための図
アクティビティ図
情報やデータの処理の流れを示す
シーケンス図
システムの構成要素間あるいはそれらとシステム外部の要素との間でどのようなメッセージのやり取りが行われるかを例示する
ステートマシン図
システムやシステムの構成要素などの振舞いを有限状態機械として表現する
モデリングツール
astah*UML
株式会社チェンジビジョン
diagrams.net
オープンソース
フローチャートや実体関連図など様々な図を作画可能
PlantUML
オープンソース
マインドマップ、ガントチャート、ワイヤーフレームなど様々な図を作画可能
テキストファイルとして保存可能
ブラウザ上
記法
始め方
startuml
enduml
ユースケース図
構成要素
アクタ
棒人間
システムと相互作用する、システム外部の相手
actor [アクタ名]
ユースケース
楕円
システムの振舞い
usecase [ユースケース名]
関連
アクタとユースケースの関連
実践
[アクタの名前] -- [ユースケースの名前]
サブジェクト
注目しているシステムやシステムの境界
長方形
2 more items...
rectangle [サブジェクト名] {[ユースケースの定義]}
記述
エイリアス
usecase [ユースケース名] as [エイリアス]
actor [アクタ名] as [エイリアス]
構成要素
ユースケース名
1 more item...
アクタ
1 more item...
目的
1 more item...
事前条件
1 more item...
事後条件
1 more item...
基本系列
1 more item...
代替系列
1 more item...
備考
1 more item...
クラス図
構成要素
クラス
3つの長方形
3 more items...
関係
依存
3 more items...
関連
4 more items...
集約
3 more items...
コンポジション
3 more items...
汎化（継承）
3 more items...
可視性
+
1 more item...
~
1 more item...
-
1 more item...
＃
1 more item...
オブジェクト図
２つの長方形
一つ目：オブジェクト名：クラス名
object <オブジェクト名>
object "<オブジェクト名>:<クラス名>" as <エイリアス名>
二つ目：属性と属性の値
<属性> = <値>
リンク
オブジェクト間に存在する具体的な関係を示す
実戦
<オブジェクト名> -- <オブジェクト名>
シーケンス図
構成要素
ライフライン
やりとりに参加する構成要素
四角形と下に伸びる破線
四角形の中に識別子を記述
典型的にはオブジェクトだが、すべてがオブジェクトとは限らない
メッセージ
ライフライン間のやりとり
矢印
3 more items...
実行仕様
やり取りの中でライフラインがアクティブな振る舞いをする期間を示す
長方形
結合フラグメント
条件分岐などの特殊なやり取りを表現
やり取りの一部を視覚で囲む
種類
3 more items...
ステートマシン図
構成要素
初期疑似状態
ステートマシン図の解視点
黒塗り円
最終状態
ステーとマシン図の最終点
黒塗り円の周りにさらに円
状態
システム等が実行時に満たす条件や取りうる状態・状況
角の丸い長方形
内部振舞い
内部遷移
遷移
状態の変化
矢印
ガード条件
トリガ
アクティビティ図
構成要素
開始ノード
黒塗り円
start
アクション
アクティビティ全体の中で実行される重要なステップ
角の丸い長方形
:<アクション名>;
フロー
アクションから次のアクションへの処理の流れの方向
矢印のついた実践
判断
条件によるフローの分岐
ひし形
条件は角括弧"[]"の中に記述
if() then (<条件>)
else (<条件>)
endif
フォーク
フローが複数に枝分かれ
太線
fork
fork again
end fork
アクティビティ終了ノード
黒塗り円の周りにさらに円
stop
ジョイン
複数のフローが合流
太線
join