絶対やってはいけない!!『危険なコンポーネントの設計と再利用の現状』

今日は

『危険なコンポーネントの設計と再利用の現状』

について説明をしをしてきた。

危ないコンポーネント開発と再利用で作られた製品を使わない「護身」のためにも本当に重要だ。

組込み・リアルタイムシステムのためのモデリングツール：C言語によるオブジェクト指向とコンポーネントベース開発

組込み・リアルタイムシステムの開発に携わるプロジェクトではC言語での開発がまだまだ主流です。

 
組込み・リアルタイムシステムの製品開発の方の多くは、これまでオブジェクト指向開発やコンポーネントベース開発に移行できないケースが多くありました。

そこで『ソフトウエアの部品化』や科学的な『派生開発』が十分実践できる解説をしました。

組込み・リアルタイムシステムの製品開発の方でも『ソフトウエアの部品化』を開発・管理できる「C言語によるオブジェクト指向プログラミング」の完全自動コード生成機能を装備しています。

C++言語の重要機能をほぼコード生成が可能です。
・カプセル化
・継承
・ポリモフィズム
・抽象クラス
・純粋仮想関数／仮想関数／非仮想関数／静的関数
・new／コンストラクタ／デストラクタ
・コピーコンストラクタ／代入演算子／比較演算子
・コンポーネントの作成と部品化
・自動推論による継承の正当性判定
・契約による設計とプログラミング
・振る舞いサブタイプ

連載記述コラム『科学的モデリング』の関連技術レポートを公開

連載記述コラム『科学的モデリング』の関連技術レポートを公開しました：
http://hsc-i.com/HSCI_TechnologyRepor.html

■タイトル：
『科学的ソフトウエアPlug＆Play』と『科学的ソフトウエア・バリアント・デベロップメント(ソフトウエア派生開発)』〜Part1

■主な内容：
①「グローバルな大競争時代」の科学的開発アプローチ
②『科学的モデリング』の理論・原理およびツール
③『ソフトウエアPLUG AND PLAY』の基本原理と効果
④『ソフトウエア・バリアント・デベロップメント(ソフトウエア派生開発)』の基本原理と効果
⑤重要理論・原理を解説しました
　•『開放閉鎖原理』
　•『先進的構成管理』と『自動デプロイメント』
　•『リスコフ置換原理』
　•『振る舞いサブタイプ』
　•『モジュラー推論』

書籍「Touch Of Class」～オブジェクト指向プログラミングの教科書

900ページ位あり分厚いが読んでいて楽しさがある本である。

哲学書ではなく、コンピューターサイエンスの本である。

学生や若手エンジニア向けであるが、日本の最近の技術書と違い専門的で緻密な専門書である。

洋書は大変ユニークな表紙デザインが多いが、この点も日本の書籍と違うところだ。

ステートマシンの設計と実装～設計のもったいお化けが出る

他の方がUMLを使って設計されたステートマシンをみると非常に感覚的描いているようだ。

　
　
ステートマシンの状態たイベントの設計には、「妥当性」や「正当性」や「有効（充足性）」という定義が明確にされており、これを意識しないで状態図を描いても得るものは何もない。
　　

「状態の入れ子」「並行状態(直交状態)」が存在するステートマシンのイベントや状態の「妥当性」や「正当性」や「有効（充足性）」という定義を知っているのいないのとでは『天と地』の差がある。
　
　

他の方が描いたステートマシンを見ると
ステートマシンの状態の「妥当性」
ステートマシンの状態の「正当性」
ステートマシンの状態の「有効（充足性）」
が無いか／あるかが瞬時で分かる。
　
　

同じく
ステートマシンのイベントの「妥当性」
ステートマシンのイベントの「正当性」
ステートマシンのイベントの「有効（充足性）」
が無いか／あるかが瞬時で分かる。
　
　

それから、並列・並行があるオブジェクト指向のクラスの状態図にもいても
同様で、ステートマシンのイベントや状態の「妥当性」や「正当性」や「有効（充足性）」であるが、こちらはもっと瞬時に異常なモデルは判定できる。
　
　　　

「妥当性」や「正当性」や「有効（充足性）」を知らない、意識しないで
設計してもこれではレビューやテストがかなり大変になってしまうから不利である。
　
設計の努力が活きないのでもったいない。

それから、状態図に登場するイベントは「ガード条件」はもちろん、イベントを送る先のオブジェクトの制約等をキチンと書こう。
　
　

pack(b:Bottle[b ∊ product])/[product' = product - {b}]
とか
pack(b:Bottle)/[b.maker.product' = b.maker.product - {b}]
である。

お絵かきモデルの状態図から卒業しないと生産性も品質も期待できない。

『科学的モデリング』技術コラムの更新のお知らせ

/**-----------------------------------------
『科学的モデリング』技術コラムの更新のお知らせ
http://hsc-i.com/TechnologyColumn.html
-------------------------------------------*/
『科学的モデリング』技術コラムを[第0回]から[第8回]までをPDFからHTML変換しました。
　
■『科学的モデリング』の技術コラムについて＆一覧
http://hsc-i.com/TechnologyColumn.html
■第0回：『科学的モデリング』の世界〜神は細部に宿る
http://hsc-i.com/TechnologyColumn0.html
■第1回：継承①〜科学的に継承を理解する準備-PART1
http://hsc-i.com/TechnologyColumn1.html
■第2回：継承②〜科学的に継承を理解する準備-PART2
http://hsc-i.com/TechnologyColumn2.html
■第3回：継承③〜継承される特性（プロパティ）
http://hsc-i.com/TechnologyColumn3.html
■第4回：継承④〜クラスとタイプ(型) 
http://hsc-i.com/TechnologyColumn4.html
■第5回：継承⑤〜継承パラドックス
http://hsc-i.com/TechnologyColumn5.html
■第6回：継承⑥〜振る舞い整合性
http://hsc-i.com/TechnologyColumn6.html
■第7回：継承⑦〜「タイプ(型)指向モデリング」のススメ
http://hsc-i.com/TechnologyColumn7.html
■第8回：継承⑧〜「タイプ(型)置換原理」と「論理状態空間」
http://hsc-i.com/TechnologyColumn8.html
　
また記事の一部を補足・修正し更新いたしました。
　
今後[第10回]以降の公開と共に,過去のコラムも適宜、補足・修正し更新する予定です。
　
＊[第0回]～[第9回]までの技術コラムが公開中です。

正確な関連のモデリングとコードへの実装の必要性②

設計モデルや実装モデルでは、「双方向関連」は、２つの片方向関連で実装する。　

 
　
関連クラスを用いる場合はちょっと事情が異なるが、本質的には同じ事である。

　
　
UMLの関連は関連先のクラスの参照、関数の引数、ローカル変数(あまり推奨されない)、グローバル変数(推奨されない)のいづれかで実装される。

これも指定しないといけない。

　
また、前方参照するのか#includeするのかも設計と実装をする上で重要な決定になる。

これも決定しないといけない。

{unique}{ordered}制約もどのように実装するのかを決定しないといけない。

　
関連(リンク)の制約が満たされているかを保証するのは、コンテナクラスを使えば楽勝だけれども、使わない場合は割と面倒である。

組込み・リアルタイムシステムでは必須になる設計・実装の決定事項である。

正確な関連のモデリングとコードへの実装の必要性①

多くの専門家の論文で議論されているように、関連が双方向で無くても両端の関連端多重度の制約を担保する必要がある。

この条件は,リンクが変更された場合,両方の参照の相互更新を必要とすることを意味する。
　
つまり、事実上両端のクラスから関連先の相手がアクセス可能でなければならない。
　
これについての多重度、関連端の可視性、関連のナビゲーションの可能／不可についてどの様にモデリングすればいいかは、多くの議論がある。
　
関連の設計と実装はソフトウエアの品質に著しく影響を与える。
不適切な関連の設計・実装が、不具合の温床になっている。
　
事を複雑にしているのは、一般的に関連のモデリングが極めていい加減にモデリングされていることである

UMTP/JAPAN(UMLモデリング推進協議会のFacebookを通じて『科学的モデリング』のご案内しました。

日本OMG(オブジェクト・マネージメント・グループ・ジャパン：http://omg.or.jp/)様およびUMTP/JAPAN(UMLモデリング推進協議会：http://www.umtp-japan.org/)様のFacebook             を通じてHSCIが提唱する『科学的モデリング』の公開しました。

[第0回]から[第9回]まで公開中です。引き続き継続して公開予定です。

■『科学的モデリング』の技術コラムについて＆一覧
http://hsc-i.com/TechnologyColumn.html

■第0回：『科学的モデリング』の世界〜神は細部に宿る
http://hsc-i.com/TechnologyColumn0.html

■第1回：継承①〜科学的に継承を理解する準備-PART1
http://hsc-i.com/TechnologyColumn1.html

■第2回：継承②〜科学的に継承を理解する準備-PART2
http://hsc-i.com/TechnologyColumn2.html

■第3回：継承③〜継承される特性（プロパティ）
http://hsc-i.com/TechnologyColumn3.html

■第4回：継承④〜クラスとタイプ(型) 
http://hsc-i.com/TechnologyColumn4.html

■第5回：継承⑤〜継承パラドックス
http://hsc-i.com/TechnologyColumn5.html

■第6回：継承⑥〜振る舞い整合性
http://hsc-i.com/TechnologyColumn6.html

■第7回：継承⑦〜「タイプ(型)指向モデリング」のススメ
http://hsc-i.com/TechnologyColumn7.html

■第8回：継承⑧〜「タイプ(型)置換原理」と「論理状態空間」
http://hsc-i.com/TechnologyColumn8.html

■継承⑨〜「リスコフ置換原理」とタイプ(型)階層
http://hsc-i.com/pdf/TechnologyColumn9.pdf

第9回『科学的モデリング』技術コラム公開～「リスコフ置換原理」詳解

第9回『科学的モデリング』技術コラムを公開いたします。
http://hsc-i.com/TechnologyColumn.html

第9回のコラムはの趣旨は：
・誰でもできる『』のクラス設計
・誰でもできる『いかなるコンテキストでも妥当な』継承の設計方法
・誰でもできるコンポーネント＆クラスの『再利用』を確実に行う継承の設計方法

です。

技術的な項目としては下記になります。

■一流モデラーになるための必修知識：
　・概念モデル／分析モデルと設計モデルの違い
　・「リスコフ置換原理」と継承階層の「意味的整合性」＆「振る舞いサブタイプ」
　・コンピューター科学による設計モデルの作成と検証の重要性
　・「リスコフ置換原理」の形式的表現

分かり易い図と具体的なクラス図およびコードイメージをふんだんに使って”やさ～しく”解説しました。

サクサク読み進めることができるように解説しました。
＊第0回～第8回までの技術コラムも公開中です。

オブジェクト指向のクラスと「代数構造」

週末は情報工学を専攻した大学生や社会人を意識した『科学的モデリング』の数学的・論理学的な話題のセミナー資料を作成した。

　

　
　
多くの若い学生や社会人のエンジニアは、ある程度のコンピューター科学をキチンと学習している。

ただし、いくつか完全に理解が十分でない部分があるので、少し補足するととてもよく理解できる。

　　
今回はオブジェクト指向の分析・設計・実装に欠かせない「代数構造」と「抽象データータイプ(ADT)」についての資料を作成した。

オブジェクト指向のクラスは、抽象データータイプ(ADT)の１つである。
ただし、厳密に言えば：
　
　　「抽象データータイプ(ADT)≠オブジェクト指向言語のクラス」
　
である。
　　

もっとも大切なことの１つは：
　
　抽象データータイプ(ADT)とは、コンピューター科学では『代数の1つ』
　
として扱われる。
　　

情報工学を専攻した大学生なら必ず習うと思う。
　　

コンピュータ科学では、実数、自然数、文字列などを含めてコンピューター上で利用するために、性質や公理を構造として定義する必要がある。
　
そこで、抽象データタイプは、データオブジェクトの集合(台集合)とその集合上に定義された1つ以上の演算、そして演算を記述する公理群で定義される。
　　

コンピューターで動作させるために、抽象データータイプ(ADT)の台(台集合)は実装上の制約がある。
　
しかし、これは抽象データータイプ(ADT)を設計し実装する時にエンジニアが検討する。

　　
抽象データータイプ(ADT)は対象の構造を代数として形式化(仕様)したものなので、実現方法は興味の対象外である。仕様的な記述をするソフトウエア開発者は、最終的にクラスとして実装する概念を、新しい抽象データータイプ(ADT)として事前に定義を行う必要ある。

　
　
抽象データータイプ(ADT)の公理は、実装が正しいことを確かめるためにrefinementや試験の拠り所なる。
　
　

つまり、設計やプログラムが抽象データータイプ(ADT)として定義された演算や公理を満足するか試験しなければならない。
　　

代数的な抽象データータイプ(ADT)は、基本となる構成子演算のみ、あるいは少しの基本演算により、他の演算を再帰的に定義していく。