既存システムを分析するコツは「システムの地図」を作ること
ビジネス系のシステム開発では、まったくの新規システム開発は少なく、すでにあるシステムの再構築プロジェクトがほとんどです。このようなプロジェクトでは既存システムを調べる作業が必ず発生します。その割には公開された情報として、既存システムを分析する方法を説明したものを見かけません。多くは開発者がその場その場で臨機応変に対応しています。 実際のプロジェクトでは開始早々この既存システムの分析で手間取り、時間を大きくロスするケースが見られます。この連載ではコストをかけずに分析するモデルベースの方法を5回に分けて紹介します。第1回目となる今回は、詳細に踏み込まずにトップダウンでモデル化していくための考え方を示します。 プロジェクトが置かれた状況 既存システムは土台にできるか 既存システムの調査分析は時間ばかりかかり、なかなか成果が現れません。そんなプロジェクトでは以下のような会話が飛び交います。 佐藤さ
要件定義支援ツール「要件のツボ」によるRDRAの実践
普段UMLを使っていない方に、UMLを使った要件定義の話をしてもなかなか受け入れられません。重要なことは要件の定義であり、UMLの表記法やツールの使い方を覚えることではありません。そこで今回から、UMLを使わずに簡単な入力でスムーズに要件定義の情報をまとめられる「要件のツボ」を紹介します。 はじめに 普段UMLを使っていない方に、UMLを使った要件定義の話をしてもなかなか受け入れられません。「要件定義したいのであってUMLを覚えたいわけではない」あるいは「要件定義を行うためにわざわざUMLを覚える時間はない」などの声が返ってきます。それはもっともで、重要なことは要件の定義であり、UMLの表記法やツールの使い方を覚えることではありません。 そこで今回から、UMLを使わずに簡単な入力でスムーズに要件定義の情報をまとめられる「要件のツボ」を紹介します。 個別の情報を「表形式」で並べて表現する 第
第5回 少しだけ高度なモデリング技術（その2）クラスの依存関係と実現関係
今回も「第4回 少しだけ高度なモデリング技術（その1）」に引き続き、高度なモデリングの考え方についてクラス図を取り上げて説明していきます。今回取り上げるのはクラスの依存関係と実現関係です。 依存関係（dependency）とは 2つのクラスの間に、なんらかの関係があり、その2つのクラス間の依存度合いが非常に弱い場合（疎結合）は、関連よりも依存関係を使うとよいでしょう。依存関係の具体的な例を図1に示します。この例は、会社には複数の部門があり、各部門には複数の社員がいるという、前回紹介したモデルに、会社が社員を雇って部門に登録するという操作と、その操作を実現するための関連を追加したものです。 図1は会社から出ている関連の線が2種類あるので意味的に分かりにくくなってしまいました。この対策を講じたモデルを作成してみましょう（図2と図3）。図2は、集約と関連名にて関連の意味を深める方法です。もう一方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SODECご来場者への特典ページ