サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
Simple to use A great class diagramscratchpad forbuilding models quickly and effectively. Utterly intuitive and frankly a joy to use. Don’t bother to read the older reviews! This is a great app! I’m a lead developer for an open sourceJava project and I’ve been using the freeiPad app for about a month.It was a little difficult to get used to a few things in the beginning, but I’ve become prett
◆ 趣旨 ＵＭＴＰでは、より広い意味でのモデリングの基礎能力を向上させる手段として、モデリング能力開発制度、略称「モデ脳」の企画を立ち上げました。 今年５月のＵＭＴＰ総会でも、＜モデ脳とは＞という演題で企画内容が発表されています。 この企画の目的は、最終的に、ソフトウエア関係者以外の学生を含めた一般の人が、日常生活の中から、身近な出来事、先人の教えなどの故事、または経済事象、科学現象などの解説をもとに自らが自由に問題をつくったり、また他の人の問題を解いたりすることで、楽しみながらモデリングの基礎能力を高めることです。 ＵＭＴＰの役割はモデ脳試験制度を中核として、そのような活動の場を提供するものです。 現在まで、ＵＭＴＰモデ脳企画委員会が中心となり、＜モデ脳と＞、＜モデ脳問題のガイドライン＞、＜お手本となる標準問題＞などの問題作成のための資料、パソコンのブラウザー上で実際に問題を解
プロジェクトの初期段階において最も重要なのは、 システムが取り扱う「もの」の概念について、チーム内で共通認識を築くことです。 これを怠りなんとなく実装を進めてしまうと、後半になって、 Aさん「あれ？この言葉ってこういう意味じゃないの？」 Bさん「え？そうじゃないよ。もしかして認識ずれてた？・・・」 ↓ 認識ズレ発覚！といった状況が発生することでしょう。 そこで、プロジェクト開始時にドメインモデル図を描くことで、 主要な「もの」の概念についてチーム内で共通認識を固めることができます。 ドメインモデル図とは、ユーザの視点で見た、システムに登場する「もの」の概念（ドメインクラス）を集めた図です。プロジェクトの用語集をクラス図風に表現した図ということにもなります。ドメインモデル図は自然言語で構成するため、要件定義や仕様の把握に有効です。 ここでは、ICONIX Process（ユースケース駆動型の
こんにちは，浦本です。 今回はUML(Unified Modeling Language)について取り上げたいと思います。 UMLとは？ UMLとは，システムの設計を様々な切り口でモデル化し図示するためのグラフィカル言語です。 オブジェクト指向設計では，設計概念を表す何らかの設計図が必ず必要になります。 なぜならば，コードだけでは，コンポーネントの構成や，オブジェクトの相互作用を 分かりやすく表現できないからです。 特に，ある程度規模の大きなシステム開発においては，設計図が無い場合， 拡張性やメンテナンス性に乏しいクラスの山が作られがちです。 設計図が無いと，システムが要求を満たしていることを保証するユニットテストも行えません。 そこで，オブジェクト指向設計を，標準化された図として表現できるUMLが役に立つわけです。 最低限必要なのはクラス図とシーケンス図 UMLには10種類以上もの図があ
Murali Krishnaはこう言う(リンク)。アジャイル開発へ効果的に移行できないという失敗は、ユーザストーリーが何たるかを理解できていないという根本的な失敗に根ざしていることが多い。 ユーザストーリーの最も重要な側面は、ユーザストーリーが要件（機能）の「スケジュール可能な」ユニットであり、スケジュールは他に依存していないということです。ユーザストーリーの「他に依存せずスケジュール可能な」特徴を実現する鍵となるのが、「ユーザ」がどう使うかという目線に立ってユーザストーリーを表現することです。そうすればユーザが実際にインタラクトできるエンドツーエンド（UIからバックエンド）に実装された機能性のユニットが手に入ります。 Krishnaはアジャイルコミュニティで多数の人々が信じている「ユーザストーリーは唯一、最良のよりどころ」を正確に描写し、Mike Cohnによる「Advantages
2章では，簡単な業務システムを例にしてUMLの記法をひと通り詳しく解説して行きます． なるべく分かりやすく具体的な例として，社員の出退勤の管理を行う，勤怠管理システムを選びました． この章は入門ということで、通常のモデリング作業でよく用いられる基本的な要素に重点を置いて説明していきます。 UMLの図と、その図に使用される要素を説明するだけでなく、イメージしやすいように、 勤怠管理システムを例にして説明していくことにしましょう。 勤怠システムの仕様 今回の例に用いるのは、社員の出退社時間を管理するシステムです。 社員は出退社処理しか行えませんが、総務の人は勤怠変更入力することが可能です。 また、次期開発では、遅刻/早退の場合には、理由を入力する機能を持たせます。 画面のイメージは図1のようになっています。勤怠変更画面のイメージは省略します。
本稿はUnified Modeling Language（UML）で絶対不可欠なダイヤグラムに関する連載の続編である。UMLのクラス図に関する前回の記事「UML’s class diagram」（注2）（The Rational Edge、2004年9月）では、クラス図の表記がUML 2.0の全ストラクチャ図の基本になっていることを説明した。今回は引き続きストラクチャ図に触れながら、コンポーネント図の詳細を解説する。 ◆ ダイヤグラムの目的 コンポーネント図の最大の目的は、システムコンポーネント間の構造上の関係を描くことだ。UML 1.1では、1つのコンポーネントがファイルや実行イメージなどのインプリメンテーション項目を示していた。残念ながら、これはCOMコンポーネントなどを示す「コンポーネント」という用語の一般的な用法とは矛盾する。UMLのリリースが進むにつれ、UMLにおけるコンポーネン
【伝わる！モデリング】はじめようUML！ 第2回：ユースケース図を学ぼう！ 著者：株式会社テクノロジックアート 照井 康真 公開日：2008/04/08（火） ユースケースの操作手順 「ユースケース」と言っても、それはユースケース図の中の楕円だけを表すのではありません。システムを実現するまでの過程では、それぞれのユースケースの詳細な操作方法を分析する必要があります。各ユースケースの詳細な操作方法は、「ユースケース記述」の中でイベントフローとして表されることが一般的です。 ユースケース記述には、ユースケース名、概要、主アクター、支援アクター、事前条件、事後条件（保障）、トリガー、基本フロー、代替フロー、例外フローなどの項目について日本語で記述します。これらのユースケース記述のテンプレート（様式）は、UML の範囲ではありませんので、プロジェクトによって異なります。 上記の項目は、一般的なユー
ユースケースとは何か？ なぜ必要か？ 今回は、だれも書いたことがない視点から、オブジェクト技術者が理解しておくべきユースケースモデルについてのノウハウを解説します。そもそも、ソフトウェア開発には、必ず開発を行う目的があります。どんなソフトウェアであってもこの目的がはっきりしないと、よいソフトウェアなど作れるはずがありません。 筆者が初心者のころ、よく「構造化されたソフトウェアを考えてみよう」とか「継承を生かした何らかのソフトウェアを作ってみよう」といったことを計画し、自作ソフトウェアを作ろうと試みたことがありました。しかし、あえなくすべて失敗に終わってしまいました。「構造化」や「オブジェクトテクニック」が目的であっては何も作れないのです。 では、ソフトウェア開発にとって最も重要なことは何でしょうか。そうです、「ソフトウェアがどのような人に、どう使われるか」ということなのです。今回は、UML
アーキテクチャのプロトタイプを作ることで、推敲（すいこう）フェイズに実現すべきコア・アーキテクチャのベースを確認します。これは、第10回「開発プロセスの上手な組み合わせ」でも説明したとおり、コア・アーキテクチャの上にユースケース単位でインクリメンタルに積み上げていくというのが反復開発の本質となります。もしもコア・アーキテクチャに根本的な問題が発生すると、反復のたびに積み上げられるユースケース機能が不安定になってしまい、以降の反復計画に大きく悪影響を及ぼしてしまいます。 そこで、ユースケース機能を載せる前に、コア・アーキテクチャを安定させることを目的として、ミドルウェアの検証および選択や、アーキテクチャを実現するための各種コンセプト・メカニズムの部分検証を行うのが、この段階におけるプロトタイピングの目的となります。 ここで重要なことは、人は誰でも最初から優れたアーキテクチャは作れないというこ
前回は、UMLを用いてアーキテクチャをモデリングするテーマとして、「配置図でモデリングするテーマ」であるシステム間連携を取り上げました。今回は、「コンポーネント図でモデリングするテーマ」について具体的に説明します。 コンポーネント図を用いてUMLによるモデリングを行うテーマは、「コンポーネントの依存関係」となります。 コンポーネントの依存関係 一定規模以上のシステムを開発する場合は、以下の4点を実現するためにシステムを複数のコンポーネント(またはサブシステム)に分割することが一般的です。 ●コンポーネントごとに開発チームを作って並行作業をしやすくする ●障害発生時の影響範囲を局所化して被害を最小化する ●障害発生時や保守時の調査範囲を限定できるようにして調査期間・復旧期間を短縮する ●障害発生時や保守時に変更箇所の影響範囲やシステム停止の影響範囲を局所化する これらのメリットを享受
アクティビティ図（Activity Diagram） アクティビティ図とは、連続する「実行」の遷移、つまり一連の｢手続き｣を表現するための図です。ある事象の開始から終了までの機能を実行される順序にしたがって記述します。 状態マシン図が実体の状態遷移を表すのに対し、アクティビティ図では実体の制御の流れを描写します。 記述例 アクティビティ図は必ず開始状態から何らかの終了状態へ、矢印で示された手順に従って実行を行います。 下の図はある会社社員が起床して出社するまでの手続きを示した例です。 【要件定義】 まず朝起きて顔を洗います。健康ならば新聞を読みながら朝食を食べ、歯を磨き、そのあと服を着替えて出社します。もし体調が悪ければ｢病気である｣と会社に連絡して処理終了です。 ひし形で表される条件分岐は排他的で、両方の制御の流れを同時に行うことはありません。 歯を磨くという制御と新聞を読むという二つの
本連載では、UMLでモデリングを行う方法を解説しています。数回にわたり、宅配便会社の業務を例にモデリングを行っていますが、今回は、ステートマシン図を用いて荷物の状態の変化をモデリングしてみましょう。 宅配便会社は、「荷物がどこにあるのか」「売上に計上されているか」「受取人が不在の場合荷物は営業所に持ち帰られているのか」など、宅配の依頼を受けた荷物の状態を管理する必要があります。こうした荷物の状態の変化は、振る舞い図に分類されるステートマシン図で示すことができます(図1)。 図1ステートマシン図による状態のモデリング 状態と状態の間の線上に書かれているのは、状態間の遷移のきっかけとなる「トリガー」です。まずは、配達員が荷物を受け取ったところから状態の管理を開始し、この状態を「集荷中」とします。その後、配達員によって荷物が営業所に持ち込まれた時点で「配送準備中」になります。続いて、送り側の営業
クラス図 モデルの静的な構造を表す図で、問題領域やシステムの構造を表現できます。 astah*では、オブジェクト図、パッケージ図、ロバストネス図も、クラス図を利用して描画できます。 リバースエンジニアリング ソースコード出力 もっと詳しく ユースケース図 システムが、利用者にどのようなサービスを提供するのかを表現するユースケース図。システムの使用機能(ユースケース)と外部環境(アクター)との関連を表します。 astah*はマインドマップも標準搭載しているので、例えば、顧客要望をマインドマップでまとめて、それをユースケースやアクターに変換する、などといった使い方も可能です。(デモ動画をみる) ユースケース記述 もっと詳しく
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
