モデル化技法とUML（ソフトウェア工学第6回）

抽象化をどこまでするのかは難しい問題と知る。

ソフトウェアモデル。モデル化技法。モデルの役割。
モデル。ソフトウェアモデル。本物ではない。実行可能ではない。視覚的、目に見える。図などを使って強調。目的は？システムのイメージを掴む。システムがどのように操作し、どのような特性を持つか？出来上がれば詳細化することにより具体的システムが出来る。ソフトウェアの作成はモデルを詳細。の化。モデル化、内容を抽象化。何を取り出すかは目的による。何を顧客に確認したいか。特性を抽象化。一つの側面。捨象。本質を取り出す。モデル化の対象。システムを理解するために逆にモデル化。問題領域自体をモデルとして抽象化。環境をシステムの相互作用を取り込む。プロセス自身をモデル化。
モデルの対象。表現するための技術。文字と図。視覚的表現。図式表現。グラフ表現。幾何学で言うグラフ。頂点と辺からなるもの。物と物の間の関係。概念。概念同士の関係。やませ。冷害に関する風。頂点に原因、原因から結果に矢印。原因と結果の関係。不必要に複雑になりがち。モデル化が上手くいかなくなる。読み手によって解釈が異なりかねない。グラフ表現を使えば良い訳ではない。頂点や辺を表すものが一貫したものであること。因果関係か時の流れか。モデルの切り取り方悪い可能性が。頂点を区別する為に区別するのは厳密さを増すが、モデルに不要なものが入ってくる可能性が。グラフ。フローチャート。データフロー図。データ構造を。モジュール構造図。プロセス間を表す。状態遷移図。何かの動きを表現するのとものの構造を表すのと。静的なものと動的なもの。静的。時間に依存しない。動的。時間によって変化。静的モデル。頂点間の線。ある関係。矢印がついている場合は別になる。動的モデル。必ず矢印を使う。制御状態が移る。ものが流れる。何かが動く。頂点や辺をどのように意味づけるか。グラフを構成する基本概念。入門的なものが重要。辺に向きがあるかないか。経路path。ループ閉路を作る。連結性。様々な側面も。UML。モデル記述の言語。モデル化言語。75年から統一的な手法を作る。97年にUML1.1。05年にUML2.0。あらゆる工程で使われるが、設定段階の早い段階で。UMLには色々な図式が。構造図。クラス図など。振る舞い図。相互作用図。静的なものと動的なものの区分は？UMLでは頂点や辺は？基本的にはグラフ図。活動図。使う点で注意。UMLで定義されている図をすべて使う必要はない。一つの図に全ての構成要素を使う必要もない。直感的に分かりやすいが故に混同を起こす場合がある。違いに注意。UMLは形式的厳密さに欠けると批判されることがある。厳密さは部分的。直感的理解を優先。厳密さが求められているときには使えない。形式モデル。形式論理学。形式言語。公理の集合と推論規則。構文規則。形式論理。使用記述言語。形式言語。状態。事象。変数の値に変化。事象の生起条件。本土と島の道路。橋。公理。一方通行。普遍条件。事象。生起条件。
モデル分析とモデル変化。モデル上での分析。性質を確認して信頼性を向上。プログラムのように動作させる事ができる？模擬的に実行。操作的意味が与えられている場合。模擬実行。状態遷移モデル。モデル検査。自動的に検証。状態遷移モデルが通常。望ましくないことは必ず起こる。例を与えてくれる。モデルの問題点を発見。反例。モデルに立ち返って直す。通信プロトコル。モデル検査。任意性恣意性。仕様をモデルが満たしていることが論理的に検証できれば良い。仕様記述言語。自動的な検証が可能。抽象度の高いモデルから出発して、より細かいレベルのモデルを作る。そのままプログラムに変換できると生産性が上がる。モデル駆動開発。記述した後に変換。UMLのメタモデル。自動化を目指すかかどうかは取捨選択の問題。モデル階層間の変換。