07

05

アーキテクトとは

2011.07.05(22:08)

自分が読んでいるメーリングリストに投稿があって、それに対して回答を書いてみました。あまりに長くなってしまったので、自分のブログに書いて、そのURLをメーリングリストに投稿しようと考えました。メーリングリストに投稿された方の許可がいただけたので公開します。

> 暑いですので、15%節電モードのスーパークールビズで投稿させてい
> ただきます(意味不明)。

暑いですねえ。ただただ暑いですねえ。暑いと聞いただけで思考一旦停止してしまいます。

> 今年の大テーマ(まだ詳細化していないのを大テーマと言って誤魔
> 化している?)は、「アーキテクト」です。
>
> テーマ選定の背景は置いておいて(って説明不足!)、アーキテクト
> をネタにして、委員の間でディスカッションしています。
> それをこちらにも飛び火、じゃなくて、コメントをいただければと思
> い、投稿させていただきました。
>
> お聞きしたいこと(・・・ってこれじゃ、警察の取調べ!)
> (1) アーキテクトとは?その役割は? ITSS のアレでいいのか?

10年使えるアーキテクチャを作れる人じゃなくって、10年使えるアーキテクチャを作り続けるチーム作りができる人。

> (2) 組込み系アーキテクトとは?他と違うのか?
>   メカ・エレキを除いたソフトアーキは存在するのか?

システム設計全体、ソフト部分だけ、パッケージだけ、タスクだけ、いろいろな単位で考えることができるでしょうけれど、どのレベルも相似形な気がします。できる人はどのレベルでも考えられるし、考えられない人はどのレベルでも難しい。10000行のパッケージでできない人は、50万行のアーキテクチャは作れないし、500万行はとても無理。システム設計への提言も難しい。

まず10000行のパッケージでやってみましょう。きっとできます。

> (3) アーキテクトはプロジェクトのどこからどこまで関係するのか?
> 責任はどこまで持つのか?
>   コンサルタントなのか?それとも最後まで責任を持つのか?

アーキテクチャ考える人と製品リリースを最後までデバッグする人と別組織にできるほど大きな会社じゃないので全部責任を持ちます。

> (4) アーキテクトの成果物は?具体的には何?

レビューシートみたいなものかな。レビューするときにチェックすることとか、レビューの進め方をまとめたもの。それとレビュー途中のアーキテクチャ資料。

結局、できちゃったいいアーキテクチャをいくら残してもいくら説明しても役にたたない。いいアーキテクチャを作る途中が大事でそこを残すのが成果物。どんな場面でどう判断してどういう順番でモデルが変化し最終的にどうしてこのアーキテクチャが選ばれたのかのほうがずっと大切。

> (5) アーキテクチャとは?

1人のひとが作ったモジュールだけきれいにできていて、それにつながっている残りはぐちゃぐちゃ、というのはだめ。全員のプログラムがきれいに書けるように、その隙間にあるしくみがアーキテクチャ。

それに加えて、現実のどろどろした、矛盾した要求、矛盾した非機能要件まで解決できて、アーキテクチャ。きれいごとだけで済まないのが、アーキテクチャ。そもそも2人以上のお客様に買っていだだくんだから。

> (6) アーキテクチャの維持管理はアーキテクトの仕事?

実際問題、アーキテクチャは作ることよりも、壊れるのを防ぐほうがはるかに難しい。

なぜか、「できちゃう」と、レビューやらなくなるチームが多いです。

最近はDSMとかいろいろな計測で崩れるのを検出することができるようになってきたけど、やっぱり難しい要求が来たときに、アプリだけで対応するか、アーキテクチャとアプリの両方で解決するかは相談してもらいたいな。

> (7) アーキテクトは会社の役職としてあるのか?報酬は?

ノーコメント。

> (8) 専任仕事としてやれるのか?兼業農家なのか?

完全兼業農家です。アプリを作れてテストまで書けるアーキテクトじゃなきゃアーキテクチャ作れない派です。

> (9) アーキテクトは個人なのか?チームなのか?

個人はありえない。同じモデルをいろいろな見方で別々にレビューしてくれるメンバーがいてくれて成立するもの。

私はプロダクトライン開発という一方向の見方で見ることができるだけ。なあんにもわかっちゃいません。だからあなたがいてくれないと困るんです。

> (10) アーキテクトの育成は?そもそも育成できるのか?

1にレビュー、2にレビュー。3、4がなくて、5にレビュー。たとえば、他のメンバーが作ったモデルのいいところをきちんとほめてあげることができればアーキテクトとして一人前。

> (11) アーキテクトが学ぶ本は?分野は?具体的には?

去年はブルース・ダグラスのリアルタイムUMLワークショップがよかったです。状態マシン設計についてここまで深く考えさせてくれた本はなかったです。今年だとDDD本がよかったです。UMLではかえってわかりにくくなることもあることに気づきました。

アーキテクト向けにいろいろいい本あります。でも本も読むけどソースコードも読んでほしいな。いろいろなオープンソースを各バージョンごとに読んだりすると、当初思ったとおりにゆかなくてアーキテクチャを試行錯誤した歴史がわかったり。やっぱり現実のある程度複雑な要求に応えている大規模クラスライブラリとか読んだほうがおすすめ。組込みならRTOSのソースコードとかもおすすめ。

> (12) アーキテクトはプロダクトマネージャ(または企画)の夢を見るか?

できるチームはほんとうによくできる。こんなに少ない人数でこんなにたくさんの機種を生み出せるなんて!

そういうチームは意志決定が早い。プロダクトマネージャの判断を待ったりしない。というかプロダクトマネージャが一緒にアーキテクチャやアプリを作っていたりする。

> (13) アーキテクトにプロジェクトマネジメントは・・・

一度にひとつしか考えられないので私には無理。

> (14) テストアーキテクトは?通常のアーキテクトと別に必要?

いろいろな見方でやることが大切という意味では、これまで通り、別にも必要。

自分が設計したものは自分でテストしなければ設計部内品質保証ができないので、やはり設計者自身アーキテクチャ自身が、同じクラス図にテスト用クラスも足して、さまざまな製品や環境でテストを繰り返せるような設計ができなきゃ。

継続的インテグレーションは設計部のお友達。

> (15) テストアーキテクチャは共通?プロダクト別?分野別?

継承を使ってもいいけど機種毎に派生クラスを作っていてはだめ、というのはテストクラスにもいえるので、そのレベルの設計努力はテスト設計でもすること。

でも、製品の場合はできるだけ共通部を再利用したいけれど、テストの場合それを最優先にするのはちょっと難しいかな。いいんです重複していても。モデル駆動にならず手作りが残っていても。どこまでもそっくりなシミュレータを現実の時間内に作るのは無理。

> (20) アーキテクトのスペルは?

アーキテクチャって使ってもらってなんぼ。たくさんの製品に使われてなんぼのもの。お客様はアーキテクチャの善し悪しで買ってくれたりはしない。アプリがよくなきゃね。アプリを作りやすくして、アプリをさらによくするための工数を生み出すのがアーキテクトの仕事。

お願いです。ほんのちょっとでいいので手伝っていただけないでしょうか。毎日が平身低頭。

> 皆様のご意見を末永くお待ちしております。
>
> # 15%水増しして書いていますので、実際の JEITA の委員会は真面目です。きっと。

回答も15%背伸びして書いていますw。

11

07

プロダクトライン開発の効果が見えるのは

2010.11.07(21:06)

プロダクトライン開発の効果

プロダクトライン開発をはじめると実際には以下のようなステップになります。話しを簡単にするため、ラインナップに属する複数の機種を1年に1回ずつまとめてリリースしているとします。

(1) まず旧機種資産の1つを選び、それを最初の年に共通部と可変部に分ける。それで最初の機種を出す
(2) 次の年に、1年目で作った共通部を使って、2つ目の機種が出せるように、その共通部と2つめの機種用の可変部とに分ける。それで2つの機種を出す
(3) その次の年には、共通部を使って、3つ以上の機種を出す。

これを見るとわかるように、最初の1年では、何も変わっていないように見えます。ソースコード行数もそれほど変わらないし、できる機種は1つだけだし、手間がかかっただけで何も効率化しているように見えません。

ほんとうに効果が出るのは2周目、2年目からです。そこでは同じ共通部から2つの機種を出すので、初めて、総ソースコード行数が削減されます。ソースコード行数が少なくなれば、品質は確実にあがります。設計を見直す効果も大きいのですが、実際にはソースコード行数が少なくなるほうが品質向上に効果が大きいです。共通部はテストも共通で済みます。

そして、めざましく効果が出るのは3周目、3年目からとなります。

図面では微妙ですが、毎年その製品に入る機能は増え続けるので、1つの機種にはっている総ソースコード行数は少しずつ増えてゆきます。共通部を増やすことと、総行数が増えてゆくのと追いかけっこになります。

また1年目の共通部と、2年目の共通部、3年目の共通部は同じではありません。少しずつ中身を入れ替えながら大きくなっています。大きくなる理由は、最初の機種であっても、そのままではなく、前年の可変部の中を、さらに、共通部と可変部に分ける取り組みを続けてゆくからです。

これらの取り組みを続けて、毎年毎年共通部を増やし可変部を少なく局所化する取り組みを絶え間なく続けることが、プロダクトライン開発の取り組みとなります。

私の知る限り、最初からラインナップ全部の製品を一度に入れ替えるというプロダクトライン開発というのは聞いたことがありません。まずは1つの機種から試してみる、一歩ずつ効果を確かめながら、徐々に加速してゆくのがプロダクトライン開発の普通の進め方だと思います。

本質的に、なかなか短期間で効果を見せることができないのがプロダクトライン開発なので、しばらくはがまんが必要です。上司があまりに短期の効果ばかり要求しているところではなかなかうまくゆかないかもしれません。

10

14

プロダクトラインへいたる道

2010.10.14(22:20)

プロダクトライン開発へいたる道は以下のようなイメージになります。

productline1.jpg

プログラムが非常に小さいうちは、mainから呼び出される単一タスクで構造化設計されたもので動作させることができます。

それが1万行を超えて数万行になると、センサやアクチュエータが増え、複数の責務を並行処理しなければならなくなり、RTOSを使ったマルチタスクで設計することが必要になります。そのとき、過去の構造化設計の一部分を取り外して、マルチタスク設計されたモジュールで入れ替えます。

さらにそれがどんどん複雑になり、それまでの一部分を取り外して、オブジェクト指向設計されたモジュールで入れ替えます。タスクはデータ隠蔽とメッセージ通信による独立した並行処理単位として有効ですが、タスクの数は無限には増やすことができないので、データ隠蔽とメッセージ通信をより小さい単位で実現できるクラスによって、オブジェクト指向開発するのが有効な手段となります。

オブジェクト指向設計の規模がさらに大きくなってくると、オブジェクト指向設計と相性がよいモデル駆動開発ツールを使って、モデルからのソースコード自動生成を活用すると、より開発が加速できます。この場合は、オブジェクト指向設計されている一部分を取り外して、モデル駆動開発ツールで自動生成したモジュールで入れ替えます。それまで手書きしていた状態マシンは、その大部分が機械によってコード生成されます。

これに対し、プロダクトライン開発は、オブジェクト指向設計やモデル駆動開発したものがさらに大規模化してきたときに対応するものです。ソースコード行数がおよそ50万行を超え、派生機種開発が従来までの方法では限界を感じるようになったとき、プロダクトライン開発が有効な解決方法となります。

プロダクトライン開発は、それまでの設計手法とは切り口が異なり、構造化設計、RTOSを使った設計、オブジェクト指向開発、モデル駆動開発しているそれぞれの範囲を横断的に2つに分けようとする開発方法です。

その2つが、共通部(図ではフレームワーク)、可変部(図ではアプリケーション)になります。複数の製品を複数世代にわたって効率よく開発できるように、共通部と可変部を分けた設計にします。

さらにこの図で強調しておきたいのが、構造化設計は最後まで残るし、すべての基本になっている、ということです。またRTOSを使った設計で解決すべきところを、オブジェクト指向で解決するのも無理です。それぞれその解決方法を正しく使うことがとても大切です。UMLで描けないところもとても大切です。

逆にいうと、オブジェクト指向やモデル駆動開発をいれればすべてうまくいく、というのは間違っているということです。構造化設計やRTOSを使った設計の全面置き換えにはなりません。ごく一部分を置き換えるだけです。

きちんと構造化設計とRTOSを使った設計ができるなら、ほんの少し、オブジェクト指向とモデル駆動開発で加速するだけで大きな効果が出るといえます。

プロダクトライン開発では、共通部と可変部を分けて作る切り口が大切になります。続く。

07

13

モデル駆動開発(MDD)の現状と課題

2010.07.13(20:26)

翔泳社さん主催で、2010 年 7 月 8 日 (木) に開かれた、
組込みソフトウェアモデリングフォーラム2010
http://codezine.jp/event/uml/2010/
のパネルディスカッションに参加してきました。

その中で、モデル駆動開発(MDD)の現状と課題について、PPT資料3枚使って説明しました。



MDDの現状では、モデル駆動開発ツールの例としてRhapsodyでどのようにしてモデルを定義し、モデルからソースコードを生成しているのかの動画デモをやったあと、現状としてどこまでできるようになっているのか、その課題はなんなのか、について説明しました。

モデルからC/C++のソースコードを100%自動生成してくれます。どうしてそれができるかというと、クラス図と状態マシン図に自分が書いたソースを埋め込んでいるからです。モデルから作り出されたコードに自分が書いたソースが組み合わさって、ソースコード全体が出てくるようになっています。

シーケンス図は、オブジェクト間のインタラクションを記録した図面です。動作確認に使います。人間がシーケンス図を描くものではありません。

モデルを動かして検証することがPC上でできます。そのとき、リアルタイムOSの動きもPC上でシミュレーションします。なので、タスク、セマフォ、ミューテックス、イベントキューもPC上でシミュレーションします。抽象インターフェースを使って動くマルチタスクアプリを書く書き方自身がプロダクトラインを実現するヒントになっています。

さらに、MDDツールはいま、プロダクトラインサポートに注力しています。1つのモデルから製品群を作り出すことがスムーズにできるように改良を続けています。



次に、MDDのいいところについて話ししました。

必然的にモデルに描ける設計にせざるを得ません。ずるができません。制約にしたがって設計することになるので、一定の品質になることが期待できます。

モデルからソースコードが出てくるので、コーディング規則の細かいところを議論する必要がなくなりました。人間がやるのはクラス名やメソッド名、変数名にわかりやすい名前をつけること、くらいです。

ソースコードはモデルに埋め込まれているので、モデルさえ構成管理しておけば、ソースコードは構成管理する必要がありません。

初期オブジェクトから関連線がつながっているクラスのソースコードだけが生成され、そのソースだけがMakefileに追加されるので、それをうまく使うとプロダクトラインをコントロールすることができます。

一番便利だと思うのが、クラスブラウザ、関連ブラウザとして使う時です。クラス図でクラスをクリックすればすばやくそのソースにアクセスできます。関連を追跡するのも容易です。あるクラスを変更するとその副作用がどこまで及ぶのか簡単にわかります。

パッケージを名前空間に割り当てたり、パッケージに入っているクラスを特定のディレクトリに生成させたり、全自動でできます。リファクタリングも1ヶ所でやれば全体に渡る変更も簡単にできます。

複数のUML図面からソースコードを生成できるので、たとえば、分析クラス図と設計クラス図の両方の見方をすることも簡単です。両方から矛盾のない単一のソースコードが出せます。

MDDは製品コードだけじゃなくて、テストスイートを作るのにも大活躍です。



ツールを初めて使うときにコツが少々あるので、C++やオブジェクト指向なども初めてだとかなり難しいです。C++やオブジェクト指向やいいモデルを作れるスキルがあって、安定した小規模パッケージをそのままMDDにするところから、ツールの壁を越えましょう。

MDDはツールです。ツールいれたからといって、いい設計になったりしません。よいモデルを作ることやよいモデルを維持するスキルはツールとまったく別に調達してください。ごみをいれるとごみしかでてきません。

最初に導入したときはもちろん製品の大部分はレガシーコードで、MDDで作り替えたところはごく一部です。なので旧資産との境界をうまくつなぎあわせるところがちょっとたいへんです。旧資産をまたがった、可変点管理、自動生成管理も必要です。昔のMakefileと、MDDツールが作ったMakefilとの折り合いも必要です。できれば凝集度が高く結合度が低いパッケージにしてからMDDに移行することをおすすめします。

構成管理ツールが、モデルをパッケージ単位で構成管理するか、クラス単位で構成管理するかも考える必要があります。プロダクトライン戦略が決まっていればスムーズですが、それも悩みます。

単純な状態マシンだとあまり困らないと思いますが、複雑な状態マシンを派生機種展開しようとすると、静的構造をデザインパターンで解決したようにはうまくいかないことに気がつくと思います。状態マシンは1つのクラスの内側にあるので、その1つのクラスの中で「デザインパターン」しなければなりません。そこで #ifdef をたくさんいれてしまっては元の黙阿弥です。

いろいろ書いてきましたが、むずかしいところ、と思っているところは、実はそれほどは困っていなくて、MDDツール的には十分満足しています。ほんとうにむずかしいところは設計者の設計スキルと、設計者間コミュニケーションや開発プロセスなどです。それらは、新しい技術をいれようとすればいつでも起きる問題ですね。それさえ乗り越えれば10倍~30倍の生産性向上も夢ではありません。

07

06

モデル駆動開発(MDD)の現状と課題 下書き

2010.07.06(23:15)

モデル駆動開発(MDD)の現状と課題 下書き

MDDの現状
  • クラス図と状態マシン図のモデル定義、およびそのモデルに埋め込んだソースを使って、ソースコード全体を自動生成。クラス図からは枠だけだが、状態マシンは全体が出てくるので高品質で効率高い。
  • シーケンス図は動作を記録して確認するためのもの。品質保証用につかう。
  • 組込み用にサポートしている言語はC/C++。十分実用的な速度でモデルからコード生成してくれる。DSL、形式検証はまだ。
  • PCシミュレーションをサポートしていて、Windows上と組込みの両方で動作するソースを生成する。状態マシンアニメーションも両方で動く。その考え方自体がプロダクトライン。
  • プロダクトラインをサポートする機能を充実中。モデルの派生機種管理に便利な機能。Variant-Variation機能、オブジェクト図上で初期オブジェクトを指定すると、そのクラスから関連があるソースだけを自動生成してくれる。


いいところ
  • モデルに描ける設計に必ずせざるを得ないので最低限の設計が守られるようになる。ずるができなくなる。状態マシン図からの生成をやる前はずるができていた。
  • コーディングルールは、モデルからのコード生成ルール。変数名や関数名をわかりやすくつけよう、というルール以外、コーディングルールを議論する必要がなくなった。
  • ソースコードを構成管理しなくてよくなった。完全なラウンドトリップが実現され、ソースコードはモデル図面に埋め込まれてチェックインされる。モデル図面が構成管理対象。
  • クラスブラウザ、関連線ブラウザ。モデルとソースが連動しているので、モデルからソースを参照したり、どこに関連しているか調べたりするのがすばやくできて、実装やレビューにとても便利。
  • 分析モデルと設計モデルをシームレスに見る。分析モデルの図面と設計モデルの図面など複数あってもそこから単一のソースが生成できる。複数の視点で段階的なレビューができる。
  • 品質保証のためのMDD。同じ設計者が製品モデルとそれをテストするモデルの両方をMDDで開発する。そうしないとリファクタリングができない。しかしそのことが品質保証のためのMDDを進めることに。


むずかしいところ+期待
  • MDDはツールでしかないので、ごみをいれるとごみがでてくる。蛸足クラスは蛸足コードになる。いいモデルを作るスキルは別に必要
  • 派生クラスをコピーペーストして、ちょっとずつ違う実装を作るなんて、とてもたやすくできる。
  • 旧資産の活用と、モデルの構成管理もいろいろ難しい。境界線はいつも悩ましい。モデルとモデルの差分をとる。
  • 状態マシンの派生機種開発が難しい。クラス構造はデザインパターンがあるが、単一クラスの中にある状態マシンの派生機種展開は難しい。PureVariantsの解、Rhapsodyの解などがあるが、、、
プロフィール

島敏博

Shima Toshihiro 島敏博
信州アルプスハイランド在住。HaskellとElixirが好き。組み込みソフトウェアアーキテクト、C++プログラマ、山歩き、美術館巡り、和食食べ歩き、日本赤十字社救急法指導員、インデックス投資、クラシック音楽、SESSAME会員、状態マシン設計、モデル駆動開発、ソフトウェアプロダクトライン、Rubyist、実践ビジネス英語

■ ツイッター
http://twitter.com/saltheads
■ Facebook
http://www.facebook.com/saltheads
■ Qiita
http://qiita.com/saltheads

印刷する場合は、ブラウザの印刷メニューではなく、このページの上から3cmくらいの青いところにある、「印刷」を押してみてください。少しうまく印刷できます。まだ完全ではないのですが、これで勘弁してください。


カテゴリ
最新記事
月別アーカイブ
最新コメント
検索フォーム
リンク
sessame
RSSリンクの表示