タグ

modelingに関するamnmaのブックマーク (5)

  • アジャイルモデリング(AM)の原則

    by Scott W. Ambler, Copyright 2001-2003 アジャイルモデリング(AM)では、ソフトウェア開発プロジェクトに適用されたときにモデリングプラクティスを導くための、一連の基原則と追加原則を定義しています。原則のいくつかはエクストリームプログラミング(XP)から採用したもので、Extreme Programming Explainedで詳しく説明されています。XPは、これらを一般的なソフトウェア工学技術の成果から採用しています。まさに再利用です。AMのほとんどの部分では、モデリング作業を念頭において原則を記述しています。そのため、XPから採用した原則も少し異なる説明になっているかもしれません。 基原則 簡潔さを心がけよう:開発時には、もっとも簡単な解決策がもっともよい解決策であると考える必要があります。ソフトウェアを作りこみすぎてはいけません。AMでは、今

  • アジャイルモデリング(AM)ホームページ

    目次: AMとは? AMの目的 AMの範囲 AMの価値、原則、プラクティスの概要 アジャイルモデリング(AM)とは? アジャイルモデリング(AM)は、ソフトウェアに基づくシステムを効果的にモデリングし、文書化するための、プラクティスに基づく方法論です。  簡単に言うと、ソフトウェア開発プロジェクトで適用できる、効果的で手軽にソフトウェアをモデリングするための価値、原則、およびプラクティスを集めたものです。  アジャイル(機敏)なモデルは、目的を達成するうえで「かろうじて使える」だけで十分であり、完璧である必要はないという割り切りのもとで作成されます。その結果、既存のモデルより効率的です。アジャイルモデリングという方法は、要求、分析、アーキテクチャ構築、設計に適用することができます。より詳しくはアジャイルモデリング(AM)とは何か?のエッセイを、今後出版されるアジャイルモデリングに関する書籍

    アジャイルモデリング(AM)ホームページ
  • アジャイルモデルのエッセンス: アジャイルに作れる成果物

    by Scott W. Ambler, Copyright 2003 効果的にアジャイルモデリングを行うには、さまざまな種類のモデリング手法を知っておく必要があります。残念ながら、これは口で言うほど簡単なことではありません。このページはまだ作成中ですが、さまざまなモデリング成果物の概要へリンクしています。各ページには、その成果物についの解説と、1、2の例、推奨文献へのリンクが含まれています。 モデリング成果物 ビジネスルール ビジネス/質ユースケース 変更案 CRC(Class Responsibility Collaborator)モデル 制約事項 取り決めモデル データフロー図(DFD) 質/ビジネスユースケース 質ユーザインターフェースプロトタイプ ユーザ機能 自由形式の図 フローチャート 用語集 Logical Data Model (LDM) ネットワーク図 オブジェクトロ

  • [Think IT] 【伝わる!モデリング】はじめようUML!

    代表取締役 東京理科大学理学部応用数学科卒業。OSF(Open Software Foundation)のテクニカルコンサルタントとしてDCE関連のオープンシステムの推進を行い、OSFベンダ協議会DCE技術検討委員会の主査をつとめる。現在、株式会社テクノロジックアート代表取締役。UMLによるオブジェクト指向セミナーの講師、UML関連のコンサルティングを行っている。UML Profile for EDOCの共同提案者、ISO/IECJTC1 SC32/WG2委員、電子商取引推進協議会(ECOM)XML/EDI標準化調査委員。明星大学情報学部講師。 http://www.tech-arts.co.jp/ 獨協大学経済学部卒業後、業務系のシステム開発を経て、株式会社テクノロジックアートに入社。現在は、UMLやオブジェクト指向技術を活かした実際の開発や、セミナー/トレーニングの講師、コンサル

  • [Think IT] 第2回:ユースケース図を学ぼう! (1/3)

    【伝わる!モデリング】はじめようUML! 第2回:ユースケース図を学ぼう! 著者:株式会社テクノロジックアート 照井 康真 公開日:2008/04/08(火) ユースケース図とは 前回は、UMLに関する全般的なお話から、業務分析でアクティビティ図を使用する方法を説明しました。今回は、要求分析でユースケース図を使用する方法を説明します。 ユースケース図は、UMLの生みの親であるスリーアミーゴスの1人、ヤコブソンがOOSEという方法論から取り入れた図です。システムが、外部から求められる機能的な要求を表現します。開発工程の中では主に要求分析段階で、開発者がユーザに機能的な要求を確認するために記述されることが多い図となります。図1は、最もシンプルな表記によるユースケース図の例です。 「サブジェクト」は、書いても書かなくてもそれほど違いはありませんが、ここでは後の説明のしやすさのために記述しています

  • 1