開発プロセスとUMLモデル Quick Tour from UMLによるオブジェクト指向モデリングセルフレビューノート - Ken's Blog
UMLによるオブジェクト指向モデリングセルフレビューノートの「1-2 UMLの図はどのように使われるか」には重要なエッセンスが詰まっています。そのエッセンスを噛み砕き、自分なりにまとめてみました。 工程 要件定義 基本設計 機能設計／詳細設計 フェーズ 要件定義 （問題領域の）分析 （ソフトウェアの）設計 世界 仕様化の世界 Whatの世界 Howの世界 焦点 要件の仕様化 問題領域の構造と振る舞いの定義 要件の抜けや矛盾の解消 実現性の観点からの要件のフィルタリング 要件の実現（WhatからHowへの転換） 冗長性を排除した最適化 アーキテクチャの組み込み 機能要件 USDM(要求/理由/仕様) 用語集/概念モデル/ドメインモデル(クラス図) ユースケース図/ユースケースシナリオ ビジネスルール (アクティビティ図/デシジョンテーブル/状態遷移表) ロバストネス図 更新したユースケース図
ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき
ユースケース駆動開発実践ガイド を読んでいます。現在、ロバストネス分析のところまで読み進めました。この本で目からウロコが落ちる体験をしています。以下、気付いた点です。 ユースケースってすごい いままでユースケース記述というのは「アクターと丸をつないだものに、他の資料（機能仕様書など）から見つけ出した説明をつけたもの」で「あまり役に立たないもの」と考えていたのですが、違いました。ICONIXプロセスでは次のことをすることで、ユースケースを設計の基本となる極めて重要な資料に仕立て上げています。 先に用語リスト（ドメインモデル）を作成し、そこに含まれる用語を使うことで曖昧さを排除する。 宣言的（例：ユーザーは検索できる）ではなく叙述的（例：ユーザーは検索ボタンをクリックする）に書く。 「事前条件」「アクター」「スコープ」「レベル」「成功時保障」などの項目を省略し、その分、モデリングに集中する。
ユースケース駆動開発実践ガイドを読んでわかったこと、その2 - paz3のおもいつき
ユースケース駆動開発実践ガイド を読んで気付いたことのメモです（そんなの当たり前だよ！」というようなこともあるかもしれませんが、ご容赦ください）。前回（d:id:paz3:20090613）の続きです。 シーケンス図のメッセージとロバストネス図のコントローラは1対1対応しなくてもよい 最初、ロバストネス図のすべてのコントローラをシーケンス図のメッセージに置き換えようとしました。たとえば「数量が足りていれば○○する」というような判断をするコントローラも、とあるオブジェクトの自分宛のメッセージとして記述しました。その結果、メッセージ（メソッド）の数が膨れ上がり、わけがわからなくなってしまいました。 書籍を読み直してみたところ、次のように書いてありました。 コントローラと操作の間に1対1の対応を取る必要はありません シーケンス図上にフローチャートを描こうとしてはいけません そこで、シーケンス図か
UMLを描こう – Vol.6 ロバストネス図からシーケンス図を描く
こんにちは、浦本です。 今回はロバストネス図からシーケンス図を描く方法について、順を追って解説します。 シーケンス図の立ち位置 シーケンス図は、詳細設計の成果物の中で最も重要な図です。描く際はいきなりゼロから描くのではなく、ロバストネス図を参考にしながら描きます。下図に、開発プロセス全体におけるシーケンス図の立ち位置を示します。 ICONIX Processでは、設計プロセスを予備設計と詳細設計の2段階に分けて行います（これを2パス設計と呼びます）。まずは予備設計で、実際のクラスを気にせずに「システム全体としてどのような処理・対話をすべきか」を先に決めます。次に詳細設計で、具体的にどういったクラスにそれらの処理を割り振るかを決めていきます。事前にロバストネス図さえ描いていれば、要件定義にきちんと結びついたシーケンス図を描くことができます。詳細設計ではシーケンス図の他にも、必要に応じてクラス
ICONIXを使った開発技法のビデオ: プログラミングが好き！
プログラミング好きが、プログラミングのためのソフトウエア開発周辺の興味ある分野を勉強する記録。プログラミング言語、IT、ICT、情報処理技術、設計技法、数値計算、データベース、システム、SCM、画像処理、開発環境、ツールなどなど。 ICONIX技法は一見シンプルで簡単そうなのだが、各図を作成する（設計する）段階でなにをどこまでモデル化すればいいのか？どのように取捨選択すればいいのか？が明確でない。ロバストネス分析について詳しく手順やシステムの良否を判断する基準を示したドキュメントも見当たらない。ロバストネス図については記法の明確なルールがなくコントローラやバウンダリをどのように分割すればいいのかわからない。 などの問題があるのでどうしても自己流になってしまいがち。 そんななかICONIX技法を説明したビデオを見つけました。 コンポーネントベース開発 第2回（2009年度） http://s
システム設計日記
テスト駆動開発 和田卓人(t-wada)さんによる『テスト駆動開発』の新訳版が出版されました。 オブジェクト指向でソフトウェアを開発するのであれば、この本とマーチンファウラーの『リファクタリング』は必読書だと思います。この古典ともいえる『テスト駆動開発』が和田さんの手によって新訳版として復刊されたことは、ほんとうにすばらしいことです。 この本が出版された経緯と、和田さんはじめ関係者の方々のご努力については、和田さんの、このブログをぜひ読んでいただければと思います。 新訳版『テスト駆動開発』が出ます 新訳本は、単に原著が日本語で読めるようになっただけではありません。和田さんの手によって、原著にはない新たな価値が付け加えらました。 一つは、サンプルコードの工夫です。 できるだけ省略はしない変更箇所を目立つようにした各章末にその時点での全コードを記載する これらの工夫により、本に書かれた内容が、
【ICONIX】 まずは、ドメインモデリングから始めよう( ･`ω･´)ﾜｯﾌｩーｗ
以前、友人たちとチーム開発をやった際に ICONIXプロセスを導入して、ユースケース駆動開発を実践したことがあります。 それから数年、使わないと人間忘れてしまうものですね・・orz 『やべぇ、ユースケース図がほんとにコードになった！ｗｗ』という感触を思い出し、後で復習出来るようにするため、 記録をつけながらもう一度実践してみたいと思います (`・ω・´) ﾜｯﾌｩー ではまず、プロジェクト(と言っても今回一人ですがｗ)の用語集にあたるドメインモデルを作りたいと思います。。 要求事項から名詞を抽出顧客などから出してもらった要求記述から、出来るだけ現実世界にある名詞(オブジェクト名)を抽出します。 内容 例
ICONIX « ツール工房 覚書
ICONIXプロセスとは開発プロセスの一つです。ユースケース駆動のプロセスであり、分析と設計のギャップを埋める「ロバストネス分析」を行うことが特徴です。 ICONIXプロセス：http://ja.wikipedia.org/wiki/ICONIX 今回は、ICONIXプロセスを用いてHSMS通信ソフトをモデリングしてみました。 ドメインモデル まず要求リストを基にドメインモデルを作成します。 （接続と送受信が出来ることを目指します。） ドメインモデルは分析麻痺に陥らないように2時間以内で作成します。また、この先のユースケース図、ロバストネス図で見つかった新しい用語は随時ドメインモデルに反映することが大切になります。が、今回はドメインモデルの更新が疎かになり、シーケンス図作成後まとめて更新となりました。更新する機会を設けなかったこと、また更新担当者を割り当てなかった事が原因だったと思います。
iconixprocess.com - このウェブサイトは販売用です！ - iconixprocess リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ICONIX - Wikipedia
この項目では、ソフトウェア開発方法論について説明しています。韓国のアニメ会社については「Iconix Entertainment」をご覧ください。 ICONIX（アイコニクス）は、ラショナル統一プロセス（RUP）、エクストリーム・プログラミング（XP）、及びアジャイルソフトウェア開発よりも前から存在するソフトウェア開発方法論である。RUPと同様にICONIXプロセスはUMLのユースケース駆動であるが、RUPより軽量である。XPやアジャイルのアプローチとは異なり、ICONIXは十分な要求と設計のドキュメントを作成するが、分析麻痺にはならないようにする。ICONIXプロセスは、4ステップのプロセスでただ4つのUML図を使用して、ユースケース記述を動作するコードに変換する。 ICONIXを他と区別する特徴は、要件定義と詳細設計のギャップを埋める方法であるロバストネス分析を使用することである。ロバ
ユースケース駆動開発BootCampはじめました - やさしいデスマーチ
昨日のこととなりますが、札幌でソフトウェアの開発プロセスの１つであるICONIXをテーマとした勉強会を開催しました。ユースケース駆動開発BootCampという名称で、TDDBCの派生です。本家TDDBCと同様に、午前中は講演中心の座学、午後から演習で実際に手を動かして体験してみるというスタイルの勉強会です。最近はこの手の体験型勉強会がテスト駆動開発などを中心に広がりつつあるような気がします。 開催の経緯 実は３年ほど前に札幌Javaコミュニティを立ち上げた時、最初の頃に行っていたのが「ユースケース駆動開発実践ガイド」の読書会でした。この本は、ユースケース駆動開発に関してICONIXというプロセスを紹介しながら解説する本です。その後、自分としても関連したプロジェクトにユースケース駆動開発のエッセンスは取り入れるように取り組んでおり、一定の成果があったと感じております。そこで、このプロセスを広
ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕は、ソフトウェアシステムの構造や処理の流れを絵で描くのが大好きです。 つうと、「UML図か」とか思われそうですが、UML図には気力が湧きません。 理由1：ナントカ図、カントカ図といっぱいありすぎる。 理由2：オブジェクト指向設計の影響が強すぎる。 UMLから派生したSysMLだと、図の種類も少ないし、オブジェクト指向風味も薄まっているようです。それでも僕には面倒な感じです。「フローチャートをめぐる迷信と妄言と愚昧」にも書きましたが、箱と矢印だけくらいの、少数の要素からなる絵がいいのです。 内容： ロバストネス図 手書きにサイコー バウンダリーとインターフェイス まとめ ロバストネス図 絵にするのは好きだがモノグサである僕にピッタリだと思えるのがロバストネス図です。ロバストネス図の要素は3つしかありません。ユースケース図の要素を入れても5つです。「ロバストネス図の概要」（http://ww
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ビジネス要求の急激な変化に対応する開発プロセスとは？
system-enablers日記
組み込みとロバストネス図の関係
http://www.iconixsw.com/index.shtml