ロバストネス分析は、ユースケースのように文章で記述された要求から分析レベルのオブジェクトを見つけ、適切な単位にまとめることができるものです。また、ソフトウェアシステムが行わなければならないことも適切な単位にまとめることができます。本稿はロバストネス分析の使い方と効果について解説します。 はじめに ロバストネス分析という用語を聞いたことはありますか？ ロバストネス分析を使うことによって、ユースケースのように文章で記述された要求から分析レベル（アーキテクチャが考慮されていないレベル）のオブジェクトを見つけ、適切な単位にまとめることができます。また、ソフトウェアシステムが行わなければならないことも適切な単位にまとめることができます。 これから、3 回に渡ってロバストネス分析について解説します。本稿にあたる第 1 回ではロバストネス分析の使い方と効果について解説し、第 2 回ではサンプルアプリケー

MAF2013 Enterprise Windows 8 – Architecture for rapid development of WinRT apps

小規模～大規模のシステム構築を検討するにあたり、システムを階層化して構築することが多くなっています。人は、複雑なものをまとめて理解することはできません。そこで、階層化しそれぞれの階層に意味づけを行うことにより対象物を理解しようというわけです。そこで本連載では、今さらかもしれませんが、n階層アーキテクチャアプリケーションについて説明したいと思います。 n階層アーキテクチャアプリケーションのメリット・デメリット n階層化アーキテクチャとは、アプリケーションを表示、業務処理、データ等、複数の階層で分割する分散アプリケーション設計手法のことを指します。 階層化にはどのような視点で分割するかによって、大きく「論理的役割」による分割と「物理的役割」による分割に分類できます。 論理的役割による分割とは、画面表示部、業務ロジック部、DB、ファイルなどのデータ格納部といった各階層の役割を意識して分割される場

過去に「 ロバストネス図113枚!!」でも取り上げたが，最近ロバストネス分析を設計の入り口にすることが多くなった。バウンダリ，コントローラ，エンティティという３つのステレオタイプは，今日のWebアプリケーションのアーキテクチャにかなりしっくりとくる。統一プロセスでも，ユースケースからクラスの発見をするために，ロバストネス分析をすることが推奨されている。 ロバストネス分析の結果のロバストネス図は，かなり直感的にシステムの構造と流れを示してくれるので，あまり実装に詳しくない人でも理解可能なようだ。システムの構造や設計に興味を持っているお客さんであれば，十分使用に堪えるシンプルさがあると思う（興味を持っていれば，が重要）。 僕が設計書と実装をできるだけ近づけるために，自動生成が効果的だと思っていることは，このエントリを読んでいる方々はご存知のことと思う。クラスを見つけるためのロバストネス分析が基

要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト 今回はアーキテクチャについてです。 レイヤー構成について、3パターンほど私が考える案を紹介します。 各コンポーネントの役割については、別途説明したいと思います。 Full Pattern 特徴 大規模アプリケーション向け。 コンポーネントを最も細分化したパターン。画面とロジックを分担して共同開発したり、フロー制御や他システム連携が多かったりするシステムに向く。 Serivceがトランザクション境界となる。 レイヤー構成 プレゼンテーション層 Action、Page、Dto サービス層 Service、Dxo ドメイン層 Logic、Dao、Entity Middle Pattern 特徴 中規模アプリケーション向け。 画面ロジックとドメインロジックを2つのレイヤーに集約させたパターン。大抵のシステムは、

本稿では、ソフトウェア要求とは何なのかを理解し、非機能要求に焦点を当て、ISO9126、要求定義プロセス、事例と解説していきます。 ※本稿は、技術評論社刊『JAVA PRESS Vol.40』に掲載された記事「機能外要求と ISO9126」を加筆、修正したものです。JAVA PRESS 編集部の了承を得た上で転載しています。 ※一切の転載をお断りします。 はじめに 私達がソフトウェアを開発するためには、ソフトウェアに対する要求 (ソフトウェア要求) が必要です。 ソフトウェア要求がなければ、そのソフトウェアには本当は必要のない機能を作ってしまったり、必要な機能を作っていなかったりするでしょうし、何よりもソフトウェアが完成したのかさえ評価できません。 そのためにも、私達ソフトウェアを開発する者は、ソフトウェア要求とは何なのかを正しく理解しておかなければなりません。 本稿では、ソフトウェア要求

非機能要件は，ユーザーの要求からは出てきにくい。エスエムジーの小森裕介氏（オブジェクトフレームワークディヴィジョン テクニカルコンサルタント）は「経験上，非機能要件の中でも，許容できるダウンタイムや操作性などはユーザーから比較的出てきやすい。しかし，信頼性や性能は意識的にヒアリングしないとあまり出てこない。拡張性に関してはほとんど出てこない」と指摘する。そのため情報システム部門側で主導的に洗い出す。ここからは事例を基にそのプロセスを見ていこう。 ◆どう洗い出すか？　ひな型を使い漏れ防止 要件をテンプレート化しておく 非機能要件は機能要件と異なり，項目レベルで業種や業務による違いが少ない。「性能」「保守性」「拡張性」「セキュリティ」など，どのシステムでも同じような項目が並ぶ。そこでエスエムジーは要件定義のテンプレートを用意し，非機能要件として洗い出すべき項目を列挙した。SEはその項目を埋めれ

「要件定義を難しくする」とクローズアップされてきたのが“非機能要件”の存在である。非機能要件とは，性能や信頼性，拡張性，セキュリティなど，機能要件以外のもの全般を指す。これらはユーザーへのヒアリングからだけでは洗い出しにくい。漏れがあると，稼働後のトラブルの種になる。こうした事態を未然に防ぐ，非機能要件の見極め方を探る。 旅行代理店のアールアンドシーツアーズは，今年10月末に予定しているホテル予約システムの稼働に向けて，今，開発の真っ最中だ。このシステムは，仕入れた航空券の在庫や宿泊の空室情報を管理するホストに，2次代理店からインターネット経由で送信されてくる予約データを受け渡すもの。 開発を主導する大平雅義システム部長は，「機能要件はほぼ固まったが，性能に関する非機能要件が懸案として残っていて悩ましい」と語る。 予約データはインターネットを介してやり取りされる。そこに含まれる顧客情報は暗

前回「製品／技術の適用と実現性の検証」までに、一通りのITアーキテクチャ設計ステップを紹介したが、それぞれのステップは独立して1回ずつ行えばよいというわけではない。前のステップの設計内容を受け継いで後続の設計を行い、設計結果を吟味して、必要に応じて前のステップの設計を見直すといった反復が、良いアーキテクチャ設計には欠かせない。 ITアーキテクチャ設計は「要件の洗い出し」「機能的アーキテクチャ設計」「配置設計」「製品／技術の適用」といった流れで行われるが、この流れは1回実施したら終わりというわけではない。製品や技術は、本来、ビジネス要求から一連の設計ステップを経て選択されるものであるが、採用技術によっては、適切な配置設計が変わるケースもある。このような場合には、前のステップに戻って、アーキテクチャ設計を見直すことが必要である。 また、いったん、ITアーキテクチャが完成しても、さまざまな観点で

前回「配置設計の手順と注意点」までの、機能的なアーキテクチャ設計と配置設計によりITアーキテクチャの骨格は出来上がる。今回のステップでは、描いたITアーキテクチャに実際の製品や技術を当てはめ、性能を検討してITアーキテクチャの実現性を吟味する。ITアーキテクチャが「絵に描いたもち」にならないためには、マシンを用いて技術検証や性能測定を行うことも重要だ。 「アーキテクチャは一見完ぺきなのに、採用した製品の問題で動かない」。このような場合、製品のせいだからITアーキテクトの責任ではないといえるだろうか。ITアーキテクトは、製品や技術の選択やITアーキテクチャへの適合のさせ方についても、当然、責任を持つべきだろう。 製品や技術の問題としては、バグなどの不具合を考えがちであるが、それだけでなく、以下のような点を考慮する必要がある。 欲しい機能がITアーキテクチャ設計上の想定どおり動作するか 開発が

前回は、HAクラスタを構築できるオープンソースソフトウェア「Heartbeat」の主な機能を紹介しました。第2回は、Heartbeatのインストール方法を解説し、さらに基本的な設定内容を紹介していきます。（編集部)

機能的なアーキテクチャ設計に続くITアーキテクチャ設計のステップは、配置設計である。ここでは、システムをどのようなトポロジーで構成し、機能をどのように配置するかを設計する。可用性、パフォーマンスといった非機能要件を適切に実現することが、このステップの設計目標だ。 アプリケーションの設計は良いはずなのに、うまく動かないシステムに出合ったことはないだろうか。システムは業務上の機能要件を満たすとともに、可用性、パフォーマンスといった非機能要件を満足させる必要がある。非機能要件を実現するうえで大きな役割を果たすのが配置設計だ。 配置設計では、「機能的なアーキテクチャの設計」で導出されたコンポーネント を、ノード上に配置していく。前回、設計した機能的なアーキテクチャを、もし図1のように配置したらどうなるだろうか。 この設計では、次のような点に問題が生じてしまう。 DBサーバへの接続数が多くなり過ぎる

連載記事「ITアーキテクトを探して」の第1回目「ITアーキテクトが備えるべきスキル標準」では、ITアーキテクトの役割を、『ビジネスの要求』に的確に応える整合性の取れたアーキテクチャの構築、としている。ビジネスの要求に応えるというのが重要なポイントで、ここがずれていては、いかに「かっこいい」ITアーキテクチャも無意味なものとなってしまう。 では次の2つの例では、どちらが良いアーキテクチャだろうか。 Aのアーキテクチャは、ネットワークにクラスタリングしたUNIXサーバを接続してWeb画面の処理を行い、ここから、必要に応じてバックエンドの既存のメインフレームの業務ロジックが呼び出すというもの。これは、典型的な3階層アーキテクチャであり、通常のオンライン・バンキングなどでは、「正しい」アーキテクチャである。これに対して、BはメインフレームとUNIXサーバの配置が逆になっており、一見、「変な」アーキ

連載1回目に当たり、まずアーキテクチャ不在のシステムがどうなるか、簡単な例で紹介しよう。インターネット・ショッピングのWebサイトを思い浮かべていただこう。インターネット上で商品のカタログを見せてオーダーを受け付けるということであれば、次のようなシステム構成でも一応可能である。 さて、このようなシステムで販売を開始後、商品に人気が出て注文が殺到したらどうなるだろうか。マシンの能力が追いつかず、注文がさばき切れなくなって、今度は苦情が殺到することになりかねない。 CPUやメモリの能力を増強して対応しようとしても、マシンを増強している間は、システムの停止を余儀なくされるし、増強しても、1台のマシンでは物理的に搭載できるCPUとメモリの限界がある。 また、このシステム構成はセキュリティ的にも問題がある。一応ファイアウォールは設置しているが、さまざまなテクニックを駆使されてセキュリティが破られ、サ