アーキテクチャ設計に有用なUMLによるモデリング 今日のシステム開発では、アーキテクチャ設計の成否がシステムの品質とプロジェクトの成功に大きな影響を与えます。このような状況になった経緯には次の要因が関係しています。 従来よりもシステムに求められる非機能要求のレベルが高まっている 高いレベルの非機能要求を実現するために、様々な技術を組み合わせてシステムを開発しなければならなくなっている 上記の状況と基幹系システムの再構築の増加などが相まって、大人数で効率よく開発するとともに、高品質を達成しなければならなくなっている** アーキテクチャ設計においては、アーキテクチャのアイデアを検討するため、アーキテクチャの妥当性を検証するため、アーキテクチャを多くの開発者に伝えるためなど、様々な動機からモデリングを行います。その際、UMLによるモデリングは優れた効果を発揮します。以下、アーキテクチャ設計の工程
前回から、架空の宅配便会社「まいにち宅配便」が開発を進めている「配達予約システム」を例にとり、UMLを用いてシステムの仕様をモデリングする方法について説明しています。今回は、システム仕様の中で重要な要素の1つである「データ」の仕様をモデリングする方法について解説します。 前回、データ仕様のモデリングを行う際、ビジネスモデリングで作成したクラス図を参考にしながら、仕様のレベルまでを詳細化する「段階的詳細化」を行う必要があると説明しました。以下、詳細化の具体的な内容を説明します。 システムの範囲に応じて図を変更 ビジネスモデリングの段階ではシステム化の範囲や他システムとの境界が決まっていないため、クラス図にはシステム化の範囲外の概念や他システムが管理するデータも含まれています。そこで、仕様化の段階で、開発対象のシステムにおいて不要なクラスや属性を取り除きます。 例えば、図1のビジネスモデリング
これまで、、「業務フローの作成」、「ユースケース図の作成」、「コンテキスト図の作成」、「配置図の作成」という4つのステップに分けて、UML図を用いてUMLでシステム要求をモデリングする手順を説明しました。しかし、当然、UMLですべてのシステム要求をモデリングできるわけではありません。 UMLが得意としているのは図で表現することが向いている分野だけです。文章や表で表した方がわかりやすい分野は別途作成する必要があります。参考までにUML以外で記述すべきシステム要求を挙げます。 システム導入の目的 システム導入で狙っている業務・経営上の目的の説明は、文章での表現が適しています。 ユースケース記述 アクターから見たシステムの振る舞いをユースケース単位で記述したものを、ユースケース記述といいます。これはシステムの振る舞いを時系列に記述するため、アクティビティ図やシーケンス図でも可能ではありますが、文
UMLを用いてシステム要求をモデリングする際の作業は4つのステップに分けられます。これまで、最初のステップの作業「業務フローの作成」、2番目のステップの作業「ユースケース図の作成」について説明しました。今回は、3番目のステップの作業として、「コンテキスト図の作成」を紹介します。 Step3:コンテキスト図の作成 DFD(データフローダイアグラム)の分野では、システムとシステム外部のデータのやりとりを俯瞰するためにコンテキスト図を用います。プロジェクトの新規メンバーにシステムを説明する際に、この図があると便利です。 コンテキスト図の例 従来のUMLでは、コンテキスト図に相当する図はありませんでした。ユースケース図ではシステムとシステム外部をモデリングできますが、データの流れはモデリングできません。アクティビティ図ではデータの流れをモデリングできますが、システムやシステム外部はモデリングできま
今回は、前回取り上げた架空の宅配便会社「まいにち宅配便」の業務について、UML図のうち、構造図に属するオブジェクト図とクラス図を用いて人・役割・場所を中心にモデリングを行っていきます。 オブジェクト図によるモデリング アクティビティ図は、UMLの図の中では「振る舞い図」に分類されます。次は、振る舞い図と同レベルの分類に相当する「構造図」を用いてモデリングしてみましょう。 今回の例では、業務フローのパーティション(役割単位で分割した領域)に設定されている「依頼主」「配達員」「届け先」などの人(役割)、「取次店」「営業所」「ターミナル」などの場所が構造図のモデリング要素になります(アクティビティ図はこちらで確認ください)。構造図ではこれらモデル要素の構造・関係などをモデリングすることになります。 まずは、構造図のうち、「オブジェクト図」を用いてモデリングします。 人・役割・場所を中心に分析し
一口にモデリングと言っても、システム開発の現場では、さまざまなモデリングが行われていますです。今回は、さまざまな視点からシステム開発におけるモデリングの対象要素について見ていき、UML 2.0のポイントについて整理しておきます。 様々な視点から見たシステム開発におけるモデリング さて、本誌の読者の多くは、システム開発に関わるITエンジニアの方であると想定しています。ただ、ITエンジニアと一口に言っても、ユーザー企業の企画部門やIT部門、ITベンダーの上流SE、アーキテクト、プログラマーなど、役割は多岐に渡っています。すべての人にモデリングに関する共通イメージを持っていただくために、以下、複数の視点からシステム開発におけるモデリングの対象要素を見ていきます。 経営から見たモデリング 経営分野でモデリングという言葉を使うことに、違和感を持たれる方もいるでしょう。しかしながら、経営目標達成指標(
システム開発を行う際、UML(Unified Modeling Language)を用いたモデリングは必須の技術となっています。加えて、UMLはビジネスプロセスのモデリングを行う際にも有用です。本連載では、未経験の人でもUMLを存分に使いこなせるようになることを最終目標として、UMLについてゼロから解説していきます。第1回はUMLの役割について整理しておきましょう。 ナレッジの可視化にも役立つUML 団塊の世代の大量退職による業務知識の空洞化が、いよいよ現実的になってきました。いわゆる「2007年問題」です。これはIT業界においても大きな問題です。なぜなら、企業の基幹システムを構築・保守してきた団塊世代の技術者の大量退職も始まるからです。そのため、企業では団塊の世代が有する業務知識やノウハウの継承に本腰を入れるようになってきました。こうした問題への対処の1つが、ブラックボックスとなった知識
MiniUMLは、.NET Framework3.5のWPF（Windows Presentation Foundation）の機能を使って開発されたUMLダイアグラムエディタです。MiniUMLという名前から分かるようにシンプルなUML（クラス図）を記述できます。本格的なUMLツールにはかないませんが、ちょっとしたアイデアをクラス図に落としてみる時に使ってみてはいかがでしょうか。 入手／実行方法 MiniUMLはCodePlexからダウンロードできます。実行するだけであれば、バイナリ形式「MiniUML, release 1.0 (binary).zip」をダウンロードします。ソースコードからビルドしたい場合は、「MiniUML, release 1.0 (source code).zip」をダウンロードします。 バイナリ形式の場合、MiniUML.exeをダブルクリックします。ソースコ
http://www.martinfowler.com/bliki/UseCasesAndStories.html ユースケースとXPのストーリーとの違いは？ これはよくある質問だが、なかなか答えがまとまらない質問でもある。XPコミュニティの人々は、ストーリーはユースケースを簡単にしたものだと捉えている。私も以前はそう思っていたが、今は別の見方をしている。 ユースケースとストーリーは、どちらも要求をまとめる（organize）方法という意味で一致している。違うのは、まとめる「目的」である。 ユースケースは、ユーザーがシステムにどう携わるか、どう使うか、といったナレーティブ（narrative）を形作るために要求をまとめていく。したがってユースケースは、ユーザーのゴールとシステムとの相互作用がどれだけそのゴールを満たすかに焦点があてられる。 一方、XPストーリー（やよく機能などと呼ばれるもの
機能要求を「ユースケース」（利用者＝アクターから見たシステムの利用場面）としてまとめ，それを基に分析設計することが一般化してきた。ところが「ビジネス・ルールを入れ込んだり，if～thenレベルのロジックまで書き込んだりと，誤った書き方をしている人が結構多い」と，日本を代表するITアーキテクトの1人，榊原彰氏（日本IBM 東京基礎研究所 IBMディスティングイッシュト・エンジニア）は指摘する。どんどん詳細化し，必要ない情報まで盛り込んでしまうのだ。 「詳細化しないと気が済まないのだろう。『分析麻痺（Analysis Paralysis）』と言える」と同氏。オブジェクト指向分析設計とプロジェクトの「見える化」を実践・推進するチェンジビジョンの平鍋健児氏（代表取締役）も同意見。「画面レイアウトなど情報量が多過ぎることが結構ある。ユースケースはシステムの目的なのに，ユースケース＝機能と考えるからそ
![[設計編]ユースケースに詳細を書いてはいけない](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
本章では、UMLのダイアグラム（図）の基本的な描き方を取り上げます。 Java言語入門レベルを卒業した方が対象ということなので、 Java言語を題材にUMLを学んで行きましょう。 厳密なものではありませんが、ソースコード付きの例を示すことで、 この章を参考にしながら図を描けることを目的としています。 ソースコードと言いましても、文法的に難しいものは出しませんので、 Java言語に対する知識がない方でも、オブジェクト指向言語に対する知識をお持ちであれば 問題なく理解できると思います。一般に取り上げられる順序とは多少異なるかもしれませんが、 今回は以下の順で図を扱います。 クラス図（パッケージ図を含む） オブジェクト図 シーケンス図 コラボレーション図 状態図 ユースケース図 アクティビティ図 コンポーネント図 配置図 それでは始めましょう。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
