「オブジェクト指向・システム開発」カテゴリーアーカイブ

「実装独立」な設計を用意することの意義

設計者の発言 – 「実装独立」な設計を用意することの意義

システムの企画・開発に際して「実装独立」の視点を持ち込むことは、業務システムを長期的に発展させるために有効な配慮だ。とくに「実装独立」な設計文書を用意することは、変転する実装技術の効果をより少ないコストで享受するための決め手となる。

再利用単位の抽象度を上げて行く点ではSoftware Factoriesの考え方とにていると思う。ここでは実装と設計という形で関心の分離をすることで、設計の再利用性を向上するとともに、設計とは時間軸の異なる実装の自由度を向上させている。ただ、Software Factoriesではもう一段進めて、設計をプロダクトラインとして共有できる部分と、対象毎にカスタマイズが必要な部分に分け、かつその開発プロセスも分離する点が違っている。
大きな枠組みとしてはSoftware Factoriesの方が利点が大きいが、その分、投資も必要になるので、プロジェクト単位に収まる程度の投資を抑えて個別アプリケーションを継続的に維持していくという点では、この『「実装独立」な設計』という考え方も有効だと思う。
元ネタ: Capsctrldays – 併せて読みたい。

SOAなんて要らない!? – ウインドウズデベロッパーマガジン9月号

吉松氏によるSOAに関する論文。この雑誌でこのような記事が載ることは珍しい。と思う。
一部引用

SOAは単独のシフトウェアではなく、企業のビジネス全体作用するシステムを構築するときの考え方なので、SOAを適用できるかを判断できるのは、システムを利用する企業の責任者だけである。企業システムの構築を、自社が存続する限り一生続くプロジェクトとして、最終的な責任を負う者がいて、初めてSOAを適用するかどうか判断できる。単独なソフトウェア開発を外注するような責任範囲でSOAを適用することはできない。

WS-*/SOAP/WSDLとSOAを単純に結びつけることは間違いだろう。少なくともそれらと結びつけられるSOAは従来のシステム連携や分散オブジェクトのパラダイムを大きく超える物では無いと思う。
Software Factoriesのセッション内容や、この論文を読んで感じたのは、これから先ソフトウェアシステム開発のテーマは継続して使用されるソフトウェアシステムの開発だと思う。実装技術の変化や、業界的な流行廃りを乗り越えいかに継続的に投資したアセットを有効活用して、作り上げたソフトウェアシステム(サービス?)を維持し、使用していくかが重要なテーマになってきているのだと思う。これは何も一度書いたソースを使い回すと言うことではなく、整理されたビジネスワークフロー、ユーザーの経験、蓄積されたデータ、ソフトウェアシステムの外観、システム管理者が持つ知見と言った物を再利用し、ブッシュアップし、時には必要に応じてスクラップビルドを行い、ソフトウェアシステムを最高のコンディションの状態のまま維持していくことであり、その方法論の確立なのだと思う。
きっともう、ビルドされて、そこにある実行ファイルがソフトウェアシステムであるとは言えないんだ。

続きを読む SOAなんて要らない!? – ウインドウズデベロッパーマガジン9月号

TechEd 2005 Yokohama 4Day #1

T1-403 Software Factories補足テキスト
萩原氏のセッションはたいてい話す内容がPPTの数倍は有るのでメモ取りが大変。
今回は何とかがんばってとったメモ内容をここに書きます。
あとでポストカンファレンスDVDをみると間違いや抜けがぼろぼろと・・・。
関心の分離
ステークスホルダそれぞれがシステムに対して持つ関心は異なり、その関心の間には開きがある。
アーキテクチャ/プロダクトラインの開発
5年/10年のスパンでアーキテクチャを考える。
→(なぜか)→
一つのプロジェクトでアーキテクチャの構築を考えることは予算/政治的な要因から難しい。従ってアーキテクチャの構築は実際のプロジェクト分離したプロセスで開発する必要がある。(時間軸の違いによる開発プロセスの分離)
プロダクトライン開発ではアーキテクチャ(プロダクトライン)とアプリケーション(プロダクト生産)の会亜hつぷろせすを分離している。
ソフトウェアファクトリ
コンポーネント再利用を求める時代ではない。(過去に失敗している。)
ソフトウェアファクトリは部品(コンポーネント)の再利用ではなく、工場/生産設備(プロセス/アーキテクチャ/プロダクトライン)を再利用する。再利用するためにフィーチャ(機能)をドメインで共通性を持つフィーチャをアーキテクチャ/プロダクトラインとして用意しておく。
フィーチャはドメイン分析の中で共通性を持つフィーチャと、案件ごと独自のフィーチャとに分離しておく。
ドメイン/視点/DSL/成果物
ドメインとは知識や関心の領域
解決領域(技術)<How>
問題領域(機能)<What>
ビューポイント・・・ビジネスプロセス視点での関心の分離
DSL・・・問題領域での関心の分離
フレームワーク・・・解決領域での関心の分離
先進的なソフトウェア構造
ソフトウェアは複数のドメインで構成される。
各ドメインでのシステマティックな再利用

  • 知識
    • ベストプラクティス
    • パターン
  • 成果物
    • プラットフォーム、ミドルウェア
    • ライブラリ
    • コンポーネント
    • アスペクト

ソフトウェア成果物への要求←成果物の管理

  • 自己完結的(メタデータ)
    • 識別するための手段
  • 他の成果物とは最小の冗長性
    • 高凝集度・低い結合度の維持し、変化に対応する。
  • 理想的には単一の関心を表現
  • 適度な適応可能性
  • 繰り返し作業を自動化、利用が容易。

振る舞いを伴う静的モデル
Ref:カタリシス http://www.catalysis.org/index.html
ソフトウェア成果物としてこのレベル(カタリシスのダイアグラム)で再利用する。(仕様レベルでの再利用)たとえば、コンポーネントではFrameworkが変更されたりしたら使えない。仕様レベルの再利用であればFxの変更や実装方法の変更があっても再利用することができる。ここから再利用できればいい→DSL
DSLとは
開発言語は技術や要求の変化に対応できない。開発言語の上にドメインに対応した抽象的なコンセプトをDSLとして乗せる。こうすることで、開発言語と、再利用対象である「ドメイン仕様」との間にある時間軸の差を解決する。具体的にはDSLのコードジェネレーション機能をその時々の実装に技術にあわせることで、DSL自体の独立性を維持する。
DSLの有効性
DSLはメタデータ(仕様/管理する単位)を使って一部コードを生成するツール。
DSLは汎用的であってはいけない。スコープを限定する。汎用的に作るのであればそれはC#のような汎用言語であってDSLではない。
DSLですべてを作る必要はない。部分的にコードを作成するような形でも良い。

KYM

AIP – 高度IT人材アカデミーコミュニティ – イベント申し込み
上のページからダウンロードできる平鍋氏のスライドで、KYM(危険予知ミーティング)とKYボードが登場し「まいりました。」という感じ。
現場に行くと毎日やるくせに、これを普段の開発現場に持ち込もうという発想が起きなかった。
確かにリスクに対してチームに周知するには良い方法だと思います。
あとは、チーム全員で本日の重点行動目標の呼称「ヨシ!」のかけ声と最後の「ご安全に!」という挨拶が重要ですね。(いやマジで、KYMでは復唱呼称は大事)

そんなに守りたいならさぁ

スラッシュドット ジャパン | 右クリックとHTMLソース閲覧の禁止を提供するソフトが登場
「そこでリッチクライアントですよ。」と言うつもりもないけど、そんなに守りたいコンテンツがあるならPDFにすればいいのにと単純に思う。

TechEd 2005 Yokohama 3Day #1

柳原さんセミナー

コミュニティとは

  • 趣味・思想・権利・財産を共有している社会的交流、人の集まり。
  • 社会学的には多様な定義がある。
    • 一定地域内であり、彼らの生活はこの地域で完結し、その関心やりがいが共通するところから一体感が抱かれ、生活様式にも一致した特徴が生まれる。(社会学的な定義)
  • 政策的概念もある。町内会、自治会、婦人会、消防団等々。

オンライン・コミュニティ

  • ネットワークの利用により地域性を超えた活動を可能にする。
    • ネット上で連絡を取り合う、意見交換を行う。
    • ホームページを存在の証にする。
    • ボランタリ/非営利な活動が多い。
  • 参考図書

Windows系ユーザーグループ

  • スポンサー付き
    • Neta/JWNTUG/PassJ
  • スポンサーなし
    • USERS GROUP/NT Commitee2
  • ベンダ主導
    • GotDotNet Japan

オンラインコミュニティの実際

  • 何を求めるか
    • 幅広い技術分野の理解
    • 業界の「あたりまえをしる
    • 社外に信頼できる知人をしる
    • いざというときに忌憚のない意見を得る
  • 参加のコツ
    • 教えてくんは悪くない
    • 自分の弱さを出すこと
    • 強がり・成功談だけでは嫌われる。

ノンスポンサードコミュニティの実際

  • 運営形態
    • 会費をどうするか
    • 会計内容は公開する

NT-commitee2会員の実態

  • 自分自身が勉強したい、議論したいテーマで講師を選定、勉強会を開催する。
  • 会員はフラットな構造、全員平等、役職はなし。
  • ただし「長老」や「仙人」は存在する。
  • 会員は推薦。
  • 会員は紳士淑女たれ

NT-Commitee2の会員

  • 全国
  • 会員がいるところで勉強会を開く

「場」の重要性

  • 文書では共有しがたい情報がある。
    • それぞれの体験、公表されていない実情
    • メンタルモデル
    • 各人のビジョン
    • 地域性

TechEd 2005 Yokohama 2Day #2

本日の受講セッションのまとめ

T1-302 .NETにおけるアプリケーションアーキテクチャ構築

Pattern & PracticeのApplication Architecture for .NETの解説。
セッション内容はこれをふまえた上でのより具体的な設計方法の解説。

【感想】
Pattern & Practiceでは触れられていない各コンポーネント内の実装方法、設計の方向性について解説されたのがよかったと思う。

T3-326 Microsoft Visual C#詳細

拡張された言語仕様、Generics、匿名メソッド、イテレータ、パーシャルタイプ、Nullable等の解説。後半はVisual Studioに追加された機能、クラスデザイナ、オブジェクトテストベンチ、リファクタリング機能、静的コード分析、コードスニペット・インテリセンスの強化、デバッグ機能の強化。

【感想】
講師の方の説明がうまい。さすがプロ。内容的にはやはり駆け足だったと思うが、自分でさわって確かめるための目次は十分提供されていたと思うので良し。

T2-320 SQL Server 2005における高信頼性、セキュリティの確保

表面領域構成ツールの使い方と、SQL 2005インストール直後の構成とそうなっていることのベースとなる思想、セキュリティ機能の強化として追加されたスキーマ煮の解説、データ暗号化機能の解説。

【感想】
頭の中でぼやんとしていたスキーマについて少しだけでもクリアになってきた気がする。暗号化機能についてはもう少しこなれてくる必要があると思う。次バージョンか。

TechEd 2005 Yokohama 2Day #1

MSKK社長による基調講演

デジタル情報の急増

  • MITの研究では人類が2004年に作成したデジタルデータは18ヘクサバイト。これが2010年には50ヘクサバイトになる。
  • デジタル化によってデータの再利用性が大きく向上した。
※以下の進化によりこの事態に対応する

ハードウェアの進化

  • ストレージの増加
    • 2007年には一般的なPCのストレージ容量が1TBになる。
  • ネットワーク技術の向上
    • ブロードバンド
    • イーサネットの帯域の拡大
    • 無線通信技術の向上UWB
  • 処理能力の向上
    • マルチコア化、マルチプロセッサ化による処理能力の向上
  • ソフトウェア技術の向上

日本のIT市場の状況

  • IT設備投資の回復
  • .NETのシェアの拡大
  • SQL Serverのシェアの拡大

TechEd 2005 Yokohama 2Day 基調講演ネタ

VS2005/SQL2005の発売日
2005/11/17日に東京で
Visual Studio 2005
SQL Server 2005
BizTalk Server 2006
の製品発表会が開催される。
ということで発売日が米国の10日遅れの11/17ということになった模様。
21:58訂正
11/17は発売日ではなくあくまでも発表会の日程だとのこと。
SQLのライセンス
ミラーリングを使う場合純粋にそのサーバーを待機側として使用する場合には追加ライセンスは不要。WitnessサーバーはExpressEditionでも動作可能であるので、実質的に必要なライセンス数は1ライセンスとなる。
ロードマップ
ロードマップのスライドがでたが、Windows Vistaの出荷が2007年になっていた・・・orz

TechEd 2005 Yokohama 1Day #2

Enterprise Library
Enterprise Library各アプリケーションブロックの使い方のデモが中心。
この内容が@ITだとか、雑誌記事になってくるとELも普及するかもしれない。他のDIコンテナ等を含めて、国内でこのようなコンポーネント/ミドルウェアが使われていかないのはたぶんリソース不足が原因。後は技術者の横のつながりがたぶんアメリカに比べて希薄なので口コミによる広まりが限られているところもあると思う。