タグ

2009年8月8日のブックマーク (5件)

  • [Think IT] 第1回:アクティビティ図を学ぼう! (3/3)

    【伝わる!モデリング】はじめようUML! 第1回:アクティビティ図を学ぼう! 著者:株式会社テクノロジックアート 長瀬 嘉秀 公開日:2008/04/01(火) 業務分析 はじめに業務分析として、業務の流れを整理していきます。 業務の流れは以前から業務フローと呼ばれていて、情報システムを構築する際には、大抵作成されていました。しかし、標準化された表記方法ではなく、コンピュータのディスクや帳票などのシステム構成も混ぜてしまった図を作っていたのが実情です。 通常、業務を整理している段階では、どこをシステム化すればよいかを検討します。しかし以前の状況は、システム化するための資料の作成段階で、すでに導入するシステムが決まっているという、おかしな話になっていました。さらに、流れは役割ごとに整理するべきですが、従来の業務フローではきちんとされていませんでした。 また、UML以外の表記としてはIDEF(

    yotasurf
    yotasurf 2009/08/08
    アクティビティ
  • [ThinkIT] 第4回:ユーザ企業がシステム評価するためのノウハウの蓄積 (2/4)

    ユーザ側から見た品質の定義は、「ユーザが発見した欠陥数の密度 = 受入テストから安定稼動までの期間に発生した欠陥数」である。今回、欠陥率が計算できたデータは67件のプロジェクトであり、欠陥数の平均値は1人月あたり0.7件であった。つまり、5人月あたり3.5個のバグということになる。 およそ500万円あたり、欠陥数が1件以内に納まっているプロジェクトの比率は40%程度であり、1つの目安値として活用できる。 133件のプロジェクトの中で、品質基準を持って開発にあったっている割合は43.6%である。JUASのIT動向調査2004では、67%の企業が品質目標を提示せずに発注していることが判明したので、今回はレベルの高い企業の回答が多かったと推察される。 さらに品質基準の有無と欠陥率を比べてみると、品質基準を持っていないプロジェクトでは欠陥率が1.42倍になることが判明した。このことは、目標を持って

  • @IT:連載:ここから始めるオブジェクト指向 最終回

    UMLの2種類の動的モデルについて「振る舞いをUMLで表現する」というテーマで、「第6回 振る舞いをUMLで表現する-相互作用図」は2つの相互作用図(シーケンス図とコラボレーション図)、「第7回 振る舞いをUMLで表現する-ステートチャート図」はステートチャート図の説明をしました。今回はアクティビティ図について説明します。相互作用図やステートチャート図を描くにはオブジェクトが必要ですが、アクティビティ図を描くのにクラスやオブジェクトは不要です。 前回宿題として挙げておきました「弁当作成」の第3のモデルを考える前に、UMLのアクティビティ図について弁当作成の例題で説明します。 アクティビティ図 アクティビティ図は処理の流れを表現するのに使用し、フローチャート図と似ています。お母さんが弁当を作成する手順は大きくは、「(1)材料を準備する」「(2)弁当を作る」という2つのステップからなります。ア

    @IT:連載:ここから始めるオブジェクト指向 最終回
    yotasurf
    yotasurf 2009/08/08
    アクティビティ
  • 鈴村さんが指南する業務フロー図の上手な書き方

    まずは,業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが(図1)である。スイムレーンに役割を書き,上から下(または左から右)に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し,矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り,業務とは複雑なものである。厳密に書こうとすると,業務フローも複雑になりがちである。しかし,分かりやすさを重視するなら,一つの業務フローに登場するアクティビティはせいぜい10~15程度にとどめるべきだ。 複雑なフローを表現したければ,一部の業務フローを別に切り出して,サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が,サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」

    鈴村さんが指南する業務フロー図の上手な書き方
    yotasurf
    yotasurf 2009/08/08
     業務フロー書き方
  • 良いシーケンス図を描くための発想法

    UMLの図法の中でも、シーケンス図はとても良く使われるものの1つです。クラス構成が複雑なアプリケーションでも、メソッドの呼び出しを順に辿っていき、それをシーケンス図に描いてみると、処理の流れが理解できたりします。 しかし、シーケンス図は、単に処理や手続きの順序を示すためのものではありません。メソッドが多かったり、呼び出す順序が決まっているからと言って、単に、呼び出されるメソッドを順に並べただけのシーケンス図を描いてしまうことがありますが、それはあまり意味がありません。 ここでは、良いシーケンス図を描くための考え方を紹介します。 処理の流れを図で示そう ここでは例として、画面Aで入力した値を、画面Bで表示するだけの、単純なアプリケーションを考えてみましょう。 このアプリケーションはとても単純ですが、きちんと設計書を書いておくことにしましょう。 ソフトウェアの仕組みは、図で示すと分かりやすくな

    yotasurf
    yotasurf 2009/08/08
    必要スキル