2018年9月26日をもちましてastah* communityの提供を終了いたしました。 今後とも、皆様に愛されるastah*をご提供できますよう、より一層の製品の向上に取り組んでまいりますので 引き続きご愛用くださいますようよろしくお願い致します。 2018年9月 astah* チーム
2018年9月26日をもちましてastah* communityの提供を終了いたしました。 今後とも、皆様に愛されるastah*をご提供できますよう、より一層の製品の向上に取り組んでまいりますので 引き続きご愛用くださいますようよろしくお願い致します。 2018年9月 astah* チーム
【改訂版】初歩のUML： 第5回 少しだけ高度なモデリング技術（その2）クラスの依存関係と実現関係 今回も「第4回 少しだけ高度なモデリング技術（その1）」に引き続き、高度なモデリングの考え方についてクラス図を取り上げて説明していきます。今回取り上げるのはクラスの依存関係と実現関係です。（2012/10/1） 【改訂版】初歩のUML（13）： UMLモデリングのノウハウ、最後の秘訣（UMLモデリングの開発過程 開発編その2） （2004/1/10） 【改訂版】初歩のUML（12）： UMLモデリングの開発過程 開発編 （2003/12/20） 【改訂版】初歩のUML： 第11回 UMLモデリングの開発過程（ビジネスモデリング編） （2003/11/15） 【改訂版】初歩のUML： 第10回 開発プロセスの上手な組み合わせ （2003/10/8） 【改訂版】初歩のUML： 第9回 UMLベー
この連載では、コンサルティングでのモデル・レビューの場、教育講座実施中、各種の勉強会などの際に良く観察される、UML表記法やモデリングに関する典型的な誤解/勘違いをとりあげて解説を加えていきます。これによって、より正確なモデルの読み書き、効果的なモデル作成など、モデリング・スキルの向上を狙います。また、必要に応じて「あまり広く知られていないが、知っていると便利」なモデル要素や表記法についても随時紹介していこうと思います。 第8回：モデルの意味的な誤り(II) 今回も前回の記事に引き続いて、「表記法としては間違っていないけれども、表現している内容(モデルの意味)に{おかしな|あやしい}ところがある」というケースをいくつか見ていきたいと思います。ここではモデルの意味的な部分/解釈に関わってくることになるので、「明らかに間違っている」とは言えない(見方によっては十分に正しい)ケースも出てきます。
【伝わる！モデリング】はじめようUML！ 第1回：アクティビティ図を学ぼう！ 著者：株式会社テクノロジックアート 長瀬 嘉秀 公開日：2008/04/01（火） UMLとは 2008年4月のThink ITの特集は「モデリング」を取り上げています。火曜日の本連載では、UMLの基本から解説してきます。今回はUMLとは何かから押さえていき、アクティビティ図について解説します。 UML（Unified Modeling Language：統一モデリング言語）とは、オブジェクト指向の分析設計の表記法として、米国の標準化団体OMG（Object Management Group）によって1997年に標準化されました。 現在は、JavaやC#など、ほとんどの開発環境がオブジェクト指向になっており、実質標準的な唯一の設計表記方法となっています。また、ISO標準にもなりましたので、名実共に完全なる世界標準
UMLにはユースケース図やアクティビティ図，クラス図など10種類のダイアグラム（図）が定義されている。それぞれのダイアグラムは，要求定義や設計，開発のどのタイミングでどのように使っても自由である。とはいえ，それぞれのダイアグラムには使いどころがある。 要求をモデルとして表現するために用意されているのがユースケース図である。その具体的な作り方を，ここから解説していこう。 必要十分な情報をモデルに盛り込むには，いきなり完成型を目指して作り始めてはいけない。四つのステップを踏むことを推奨する。 ステップ1: アクターを識別 最初のステップは，システムにかかわるアクターを識別することである（図1）。アクターとは，エンドユーザーや保守担当者，他システムなどシステムとかかわる外部の存在を指す。 アクターとして定義されると開発対象外となるので，このステップによってシステム開発の境界線を明示することができ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
