Online diagramming tool for collaborating on wireframes, flowcharts, and more
Cacoo - Web上で図の作成とリアルタイムコラボレーション
Online diagramming tool for collaborating on wireframes, flowcharts, and more
キミの設計に「トレーサビリティ」はあるか
2 分析モデルを設計するまでの各工程の詳細 ビジネス要求の分析から機能の設計までの流れを図にすると、図3のようになります。 2.1 ビジネス要求の分析 ビジネスモデルが不明確で曖昧（あいまい）な場合は、どのようなビジネスモデルなら目的を達成できるかを検討し、それを実現するためのビジネスモデリングを行います。As-isモデル（現状）を分析し、目的を達成するためのTo-beモデル（未来）を検討します。すでにビジネスモデルの概要がある場合は、ビジネスプロセスを明確化し、プロセスを業務フローで詳細に定義することで、ビジネス要求を定義します。ビジネス要求の分析には、データフローダイヤグラムを利用した構造化設計手法や、UMLを利用したRUPをベースにしたビジネスモデリングの手法があります。これらの手法をカスタマイズし、プロジェクトに合った手法を適用することがよいでしょう。 2.2 システム要求の分析
- UML超入門_第2章
2章では，簡単な業務システムを例にしてUMLの記法をひと通り詳しく解説して行きます． なるべく分かりやすく具体的な例として，社員の出退勤の管理を行う，勤怠管理システムを選びました． この章は入門ということで、通常のモデリング作業でよく用いられる基本的な要素に重点を置いて説明していきます。 UMLの図と、その図に使用される要素を説明するだけでなく、イメージしやすいように、 勤怠管理システムを例にして説明していくことにしましょう。 勤怠システムの仕様 今回の例に用いるのは、社員の出退社時間を管理するシステムです。 社員は出退社処理しか行えませんが、総務の人は勤怠変更入力することが可能です。 また、次期開発では、遅刻/早退の場合には、理由を入力する機能を持たせます。 画面のイメージは図1のようになっています。勤怠変更画面のイメージは省略します。
あなたはテキスト指向、それともダイヤグラム指向？
あなたはテキスト指向、それともダイヤグラム指向？：UML BASIC LECTURE（1）（1/2 ページ） ユースケースのわな：機能 vs. 価値の提供（サービス） 書籍や文献、セミナーなどが増えてきた関係で、ユースケースという技法が数年前と比較するとだいぶポピュラーになってきました。いろいろなところで話をするときも、以前は「ユースケースって何」といった入門的なところからの話題が多かったのですが、いまは「本当はどこまで書けばよいのか」「どうすれば効果的に使えるのか」といった実践的な部分に関心が移ってきているようです。実はそれはUML全体にもいえることなのですが、特にとっつきやすいユースケースにおいて、最も顕著であるといってよいでしょう。 とはいえ、ユースケースの考え方自体はそれほど新しい概念ではなく、もともとの発想は1967年といいますから、業界的には古い考え方といってもよいかもしれませ
正しい設計と理想的なモデル
現在では、開発現場で「UML」という言葉が一般化し、「オブジェクト指向」という言葉もごく当たり前のように使われるようになりました。実際にプロジェクトの中で、UMLを用いて分析／設計を行い、開発を進めている開発者や、これから始めようとしている開発者もかなりの数に上ると思います。 しかし、「UMLの表記方法や、ビジネスモデルをオブジェクト指向で分析する方法は、ある程度理解できるのだが、実際に出来上がった分析モデルをどのように設計モデルにしていくか？」または「設計モデルは作成したが、出来上がった設計モデルは、実際にどれほど有効なのか？」という疑問を持っている方も多いと思います。本連載では「良い設計モデルとは何を意味するのか？」「どうすれば良い設計モデルを作ることができるのか？」というテーマについて、前後編の2回で皆さんと一緒に考えていきます。 前半は分析／設計モデルに関する概念的な解説を行い、後
【改訂版】初歩のUML 第13回 UMLモデリングのノウハウ、最後の秘訣
アーキテクチャのプロトタイプを作ることで、推敲（すいこう）フェイズに実現すべきコア・アーキテクチャのベースを確認します。これは、第10回「開発プロセスの上手な組み合わせ」でも説明したとおり、コア・アーキテクチャの上にユースケース単位でインクリメンタルに積み上げていくというのが反復開発の本質となります。もしもコア・アーキテクチャに根本的な問題が発生すると、反復のたびに積み上げられるユースケース機能が不安定になってしまい、以降の反復計画に大きく悪影響を及ぼしてしまいます。 そこで、ユースケース機能を載せる前に、コア・アーキテクチャを安定させることを目的として、ミドルウェアの検証および選択や、アーキテクチャを実現するための各種コンセプト・メカニズムの部分検証を行うのが、この段階におけるプロトタイピングの目的となります。 ここで重要なことは、人は誰でも最初から優れたアーキテクチャは作れないというこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
