「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
システム開発技術
詳細 †
システム要件定義 †
プライバシデザイン †
個人情報が適切に取り扱われるよう考慮したシステム設計をすること。
アジャイル開発 †
- INVEST（インベスト）
ユーザー・ストーリーの評価の６つの観点
- Independent（独立している。）
ユーザー・ストーリーが独立しており、任意の順序で作業できる。
先行するストーリーが完了してないと始められない、など他の影響を受けない。
- Negotiatable（交渉可能である。）
ストーリーが具体的なタスクに落ちすぎておらず、
顧客やプロダクトオーナーとプログラマが協働して実現方法を決められる。
- Valuable（価値がある。）
ストーリー単独で顧客にとっての価値があること。
- Estimatable（見積もり可能である。）
ストーリーを実現するのにかかる時間が見積もり可能である。
（他ストーリーとの相対時間は）優先順位を決めるのに役立つ。
- Sized Right (Small)（適切な大きさである。）
小さく適正でスコープを把握し易い。
- Testable（テスト可能である。）
そのストーリーが完了したかどうかをテストできること。
受け入れ条件が明確になっていること。
システム方式設計 †
機能要件・非機能要件 †
- 機能要件
業務の観点からソフトウェアが何をするか。
- 非機能要件
性能面やセキュリティ面等において実現するべき要件。
- 利用者要件
利用者の観点から、ソフトウェアに対するニーズ。
この要件は、機能要件と非機能要件の両方が対象になる。
システム開発におけるテスト †
共通フレーム 2013 JIS X 0160:2012のシステム開発におけるテスト
| システム方式設計 | ソフトウェア方式設計 | ソフトウェア詳細設計 |
| システム結合テスト | ソフトウェア結合テスト | ソフトウェアユニットテスト |
システム開発プロジェクトのライフサイクル †
デマルコが提唱したシステム開発プロジェクトのライフサイクル
←予算・スケジュール┐┌物理的要求→（ハード調査）──ハード───┐
↑↑ │ ↓
→ユーザの要求→（調査）→フィジスタ→（構造化分析） │システム （システム開発）→システム
↑↓ ↓構成データ ↑
───→ユーザの要求┘└構造化仕様書→（構造化設計）─設計・テスト┘
ソフトウェア要件定義 †
論理データモデル作成 †
- トップダウン・アプローチ
企業の情報戦略に基づきTO-BEを検討しつつ論理データモデル作成
- ボトムアップ・アプローチ
AS-ISを集めつつ改善を加え論理データモデル作成
- 最終的に、
業務に必要な属性を備えた正規化された論理データモデル
が作成されるのは、トップダウンでもボトムアップでも同じ。
階層化されたDFD †
- 子プロセスは親プロセスと入出力の数が同じである必要がある。
- DFDの書き方は簡単だが、以下の様なプロセスは記法に誤りがある。
UML図（UMLのダイアグラム） †
- 一覧の可視性
- （＋）：Public
- （－）：Private
- （＃）：Protected
- （～）：Package(internal)
- クラス図の書き方
関係の書き方はER図ライクだが、
データの関連に留まらず、以下の点が異なる。
- インスタンスレベルの関係
- リンク
オブジェクトのインスタンス間の関係
- 関連
オブジェクトの参照
- 集約
データの関係で部分を表す。
- コンポジション
集約と同じだが、部分の共有が不可能である点が異なる。
- クラスレベルの関係
- 汎化・特化
クラスの継承関係
- 実現
抽象クラスやインターフェイスの利用
- 一般的な関係
- 依存
インスタンスへの変更が、他のインスタンスへ影響を与えることを示す。
- 多重度
ER図と同じだが、データだけでなく参照の多重度でもある。
- 各種、UML図（UMLのダイアグラム）
- 構造図
- クラス図
- オブジェクト図
- コンポーネント図
- パッケージ図
- 配置図
- 複合構造図
- 振る舞い図
- ユースケース図
- アクティビティ図（フローチャート
- ステートマシン図（状態遷移図
- 相互作用図
- シーケンス図
- コミュニケーション図（コラボレーション図）
- 相互作用概要図
- タイミング図
CRUD図 †
- エンティティのライフサイクル分析
- 機能の過不足を確認できる（例えば、削除機能が無いなど）。
SysML †
- SysML : Systems Modeling Language
- システムズエンジニアリングのためのドメイン固有モデリング言語。
- (UML)のサブセットにUMLのプロファイル機構を使って拡張したもの
- 各種システムやSoSの仕様記述、分析、設計、検証、評価に使う。
- SoS (System of System)
複数のシステムを組み合わせて全体で一つとして利用者に提供されるシステム
- パラメトリック図を使用して、
システムの要素間のパラメタについて、
その制約条件を数式で表現すると言った事が可能。
- アクティビティ図を使用して、
連接、反復、選択の記述パターンで処理の流れを視覚化する。
- 内部ブロック図を使用して、
ソフトウェア構造を視覚化する。
ソフトウェア方式設計 †
品質特性 †
JIS X 25010:2013 で定義されており、以下のものがあるが、
モジュール化 †
- 分割技法
業務系は、業務側がSTS分割（縦）＋TR分割（横）、
基盤側が、共通機能分割みたいな感じで設計してるな...。
- データの流れに着目
- STS分割
Source（入力）、Transform（変換）、Sink（出力）
と、DFDと親和性の高そうなモジュール分割技法
- TR分割
トランザクション単位にモジュール分割する。
トランザクションごとの処理が異なる場合に適する。
- ジャクソン法
入出力データの構造に着目して機能分割を行う方法の1つ。
入力データの構造と出力データの構造の関係からプログラムの構造を導き出す。
- ワーニエ法
入出力データの構造に着目して機能分割を行う方法の1つ。
モジュールと言うより、データ処理の制御構造をプログラム構造に反映させる。
- 結合度の評価尺度
結合度の低い順（結合度は低い程、良い）
- データ結合（引数）
- スタンプ結合（構造体引数）
- 制御結合（制御に関する引数）
- 外部結合（グローバル変数）
- 共通結合（グローバル構造体）
- 内容結合（内部データを参照...言語的にはサポートされていない）
- 強度の評価尺度
強度の高い順（強度は高い程、良い）
- 情報的強度（データでまとめたインスタンス・メソッド）
- 機能的強度（１つの機能を実現するためのクラス、メソッド。）
- 連絡的強度（逐次的であることは問題、業務、データ、機能に関連している）
- 手順的強度（手順的であることは問題、業務に関連しているタメ）
- 時間的強度（時間的であることは何かしら関係がある可能性がある）
- 論理的強度（類似機能をまとめたスタティック・メソッド的な）
- 暗号的強度（定義不可なまとまり）
コンポーネントベース＆イベント・ドリブン、MVC †
- コンポーネントベース＆イベント・ドリブン
１画面１モジュール、複数イベント・ハンドラとカッチリ決まる。
- View（画面）
- Codebehind（イベント・ハンドラ）
- 業務ロジック、データアクセス
- MVC
Controllerをデータに対応させるか、
画面に対応させるか。自由度が高い。
- Model
- Model → ViewModel?(POJO, POCO)
- 業務ロジック、データアクセス
ソフトウェア詳細設計 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
