[Think IT] 第1回：アクティビティ図を学ぼう！ (3/3)
【伝わる！モデリング】はじめようUML！ 第1回：アクティビティ図を学ぼう！ 著者：株式会社テクノロジックアート 長瀬 嘉秀 公開日：2008/04/01（火） 業務分析 はじめに業務分析として、業務の流れを整理していきます。 業務の流れは以前から業務フローと呼ばれていて、情報システムを構築する際には、大抵作成されていました。しかし、標準化された表記方法ではなく、コンピュータのディスクや帳票などのシステム構成も混ぜてしまった図を作っていたのが実情です。 通常、業務を整理している段階では、どこをシステム化すればよいかを検討します。しかし以前の状況は、システム化するための資料の作成段階で、すでに導入するシステムが決まっているという、おかしな話になっていました。さらに、流れは役割ごとに整理するべきですが、従来の業務フローではきちんとされていませんでした。 また、UML以外の表記としてはIDEF（
プログラマの思索
「システムアーキテクチャ構築の原理」を読んでる。 平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」を読み直して、理解が深まった。 平鍋さんの記事に触発されたので、理解できたことをラフなメモ。 間違っていたら後で直す。 【参考】 『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita 「システムアーキテクチャ構築の原理」の感想: プログラマの思索 【1】「システムアーキテクチャ構築の原理」を読んでいて分かりにくかったことは、ビュー、ビューポイント、パースペクティブという概念が出てきて混乱したこと。 これらの言葉は何を表しているのか、具体的に理解できていなかった。 平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」では、概念モデルでまと
根本から理解するオブジェクト指向分析/設計
具体論に入る前に，まずオブジェクト指向分析/設計とは何を意味するのかを定義しておきましょう＊1。 そもそも「分析」とはどういったことを指すのでしょうか。辞書を引いてみると，“ある事柄の内容・性質などを明らかにするため，細かな要素に分けていくこと”とあります。オブジェクト指向分析を適用する場面で明らかにしたい事柄とは，どのようなシステムを作らなければならないのかということです。つまり，オブジェクト指向分析とは，“どのようなシステムを作らなければならないのかを，オブジェクトという要素を使って解明すること”ということになります。これに対しオブジェクト指向設計とは，“分析によって明らかにしたシステムの実現手段を，オブジェクトという単位を使って明確にすること”となります。 両者の違いがイメージできたでしょうか。では以降は，具体的なサンプルに基づいてオブジェクト指向分析/設計の仕方を見ていきましょう。
第11回 UMLモデリングの開発過程（ビジネスモデリング編）
第10回「開発プロセスの上手な組み合わせ」では、開発プロセスと開発フェイズ（注1）について説明しました。さて、開発フェイズが進んでいくうちに、UMLベースのモデルはどのように変化するのでしょうか。その変化とは、詳細化のための変化でしょうか、それとももっと別の変化なのでしょうか。今回は、UMLを使ったビジネスモデリング手法の基礎を説明します。特にビジネスモデリングにおけるアクティビティ図の利用法について詳しく説明していきます。そして、次回は開発段階におけるモデリング手法についての説明を行う予定です。 いよいよ「初歩のUML」もクライマックスを迎えます。もう一息でゴールです。頑張って読み進めてください。 （注1） 分析、設計、実装、テストのようないわゆる工程。UP（Unified Process）、RUP（Rational Unified Process）では、ワークフローまたは「Discip
＠IT：連載：【改訂版】初歩のUML
ユースケースとは何か？ なぜ必要か？ 今回は、だれも書いたことがない視点から、オブジェクト技術者が理解しておくべきユースケースモデルについてのノウハウを解説します。そもそも、ソフトウェア開発には、必ず開発を行う目的があります。どんなソフトウェアであってもこの目的がはっきりしないと、よいソフトウェアなど作れるはずがありません。 筆者が初心者のころ、よく「構造化されたソフトウェアを考えてみよう」とか「継承を生かした何らかのソフトウェアを作ってみよう」といったことを計画し、自作ソフトウェアを作ろうと試みたことがありました。しかし、あえなくすべて失敗に終わってしまいました。「構造化」や「オブジェクトテクニック」が目的であっては何も作れないのです。 では、ソフトウェア開発にとって最も重要なことは何でしょうか。そうです、「ソフトウェアがどのような人に、どう使われるか」ということなのです。今回は、UML
良いユースケースを書くための発想法
システムの要求仕様を決めるのに、ユースケースを使うことがよくあります。 しかし、ユースケースは上手く書けない、何を書けば良いのか分からない、という人も、少なくありません。 たいていのユースケースは、アクターが１人２人いて、アクターが行える操作がいくつか丸で描かれて、それらが線で結ばれているだけの、とてもシンプルなものです。しかし、シンプルすぎて、何の役に立つのか分からない、という人もいます。 役に立つユースケースを書こうとして、細かいことまで書き込みすぎてしまう人も良く見かけます。しかし、それは誤りです。 ユースケースは何のために書くのでしょうか。ここでは、ユースケースの目的をはっきりさせて、良いユースケースを書くための考え方を紹介します。 開発者は、細かいことまでユースケースに書き込みがち Design Wave Magazine 2007年5月号別冊付録「組み込みシステム開発者＆LSI
＠IT：良いユースケースを書くコツを伝授
［Interview］ 良いユースケースを書くコツを伝授 2003/1/22 ユースケースはシステムの機能要件を設計者、プログラマ、テスター、ユーザー、そのほかの利害関係者に伝える重要な役割を持つ。UMLを学ぼうとするエンジニアにとって、ユースケースは、クラス図と同様、最初に目にする基本的なダイアグラムだが、基本だからこそ、その真髄は非常に奥深い。良いユースケースを書くうえで、初心者が陥るワナ、回避するコツなどを来日した米ラショナルソフトウェアの要求管理部門エバンジェリスト ジム・ヒューマン氏（Jim Heumann）に聞いた。 ――良いユースケースと悪いユースケースがある。その定義の違いは。 ヒューマン氏 良いユースケースというのは、機能要件を知るべき人々にとって円滑なコミュニケーションを可能にするユースケースのことだ。理解しやすく、簡潔だが必要な情報は十分に盛り込まれている。一方、悪い
Part3 分析・設計手法の基本は「モデル作成」にあり
オブジェクト指向分析・設計の基本は，適切な「モデル」を作成することである。ここではオブジェクト指向に基づいた分析・設計手法の難しさを述べるとともに，具体的なモデルの内容，作成手順を解説する。オブジェクト指向では「分析―設計―実装」を反復することで開発を進める。 近年のオブジェクト指向の広がりには，目を見張るものがある。例えばオブジェクト指向の分析・設計モデルを作成する「UML（Unified Modeling Language）」の解説書や雑誌の記事は，今や世にあふれている。加えてUMLによる分析・設計スキルを認定する資格が登場するなど，オブジェクト指向の認知度は確実に向上していると言えよう。 しかし，オブジェクト指向関連製品や技術がこれだけ普及しているのとは裏腹に，その基本原理であるはずのオブジェクト指向分析・設計技法が正しく実践されているとは言えない。UMLとJavaを使ってシステムを
実践ロバストネス分析 第1回 ロバストネス分析の基礎 | オブジェクトの広場
ロバストネス分析は、ユースケースのように文章で記述された要求から分析レベルのオブジェクトを見つけ、適切な単位にまとめることができるものです。また、ソフトウェアシステムが行わなければならないことも適切な単位にまとめることができます。本稿はロバストネス分析の使い方と効果について解説します。 はじめに ロバストネス分析という用語を聞いたことはありますか？ ロバストネス分析を使うことによって、ユースケースのように文章で記述された要求から分析レベル（アーキテクチャが考慮されていないレベル）のオブジェクトを見つけ、適切な単位にまとめることができます。また、ソフトウェアシステムが行わなければならないことも適切な単位にまとめることができます。 これから、3 回に渡ってロバストネス分析について解説します。本稿にあたる第 1 回ではロバストネス分析の使い方と効果について解説し、第 2 回ではサンプルアプリケー
システム開発にUMLを適用するためのFAQ
※本稿は、著者達が1年前に執筆したCQ出版社刊 『Design Wave Magazine 2004 December』 [9] の記事を参考に Web へ公開したものです。 目次 UMLはオブジェクト指向なしで使えるのでしょうか？ UMLには図がたくさんあるが、全部使う必要はあるの？ いつ、どの図を使うべき？ 忙しくてモデルを書いている時間はない。ほんとうにモデルを書く必要があるの？ オブジェクト指向は、私の担当している組み込み製品にとってはオーバースペックなのではないかと思うのですが？ タスク、割り込み等、組み込みシステム特有の概念をUMLで表現できるのか？ 今からUMLを始めるのだが、UML 2.0を学ぶべき？ 製品知識は分かっているのに、分析する意味はあるの？ 機能が多すぎてユースケースが爆発してしまいます。ユースケースの管理しやすい方法を教えてください。 「問題領域の概念を抽出す
OGIS-RI OBJECT SQUARE
今月もオブジェクトの広場をどうぞお楽しみください。記事に対する感想は、ぜひ公式Facebookページのコメント欄までお願いいたします。（2024.06.26） もっとじっくり AWS CDK のコンセプト 第7回 トークン AWS CDK アプリを開発していると、ふいに ${Token[TOKEN.101]} のようなちょっと変わった見た目の値を目にすることがあります。それが今回とり上げるトークンです。いえ、正確にはエンコードされたトークンです。 トークンはあちこち見えないところで、いつのまにか使っているものです。普段はあまり気にする必要のないその仕組みについて、背景にある課題や関連する概念とともにじっくり見ていきましょう。 はじめての自然言語処理 第31回 OpenAI text-embedding-3-large と Cohere Rerank 3 の精度評価 今回は OpenAI t
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Persistence is Power:はじめての業務分析(思い出しながら) - livedoor Blog（ブログ）
ロバストネス図について
bcm連載: UMLの基礎と応用