Based on some developer's experiences with CASE tools, the following definition seems to apply: "CASE: An organized procedure for going wrong with confidence and certainty". However, this should not be the situation if this powerful tool is utilized correctly. Here are some quick considerations for using this software engineering technology:
CASEツールを使った開発者の経験によれば、「CASE：自信と確証を持ちつつ失敗に至る組織化された手法」と定義される。しかし、この強力なツールは正しく使いさえすれば、結果は違うものになる。このソフトウェア工学技術を利用する際の考慮点を、以下に述べる。：
If the target technological environment is already known, select the CASE tool which is the most suited to that environment, and utilize it throughout the analysis, design, and possibly even the construction phases.
対象の技術環境が判っていれば、その環境に最適のCASEツールを選択し、分析、設計、更に可能なら構築段階にも利用する。
Many database and programming language vendors now provide companion CASE tools to their products, or sometimes build the functions directly into the product. This can sometimes provide productivity savings through the integration that a "stand alone" CASE tool may not provide. This helps to leverage the modeling efforts of the team by producing deliverables which are directly applicable to the construction effort.
現在では、多くのデータベースとプログラミング言語ベンダーが、それらの製品に適用するCASEツールを提供している。また、しばしば、製品にその機能を組み込んでいる。これは、その統合化により単独製品のCASEツールに比べて高い生産性を可能にしている。これは、システム構築にそのまま使える成果物が生成出来、チームのモデル化作業を改善するのに有効である。
Before beginning any modeling activity, determine both the objectives and the expected deliverables for each planned development step, then utilize the CASE tool capabilities which match these development requirements.
モデル化作業に先立ち、計画されている開発段階の目的と求められる成果物を明確にし、それから開発の要件に合わせてCASEツールの機能を選択適用する。
The key is to avoid wasting time creating models or definitions which are not even called for as a part of the development activity. Just because a CASE tool manufacturer added a certain function or feature in the tool, doesn't automatically mean that it must be utilized. This is the classic example of substituting a CASE tool for a methodology. Determine what is important to produce, then use the specific abilities of the CASE tool to produce it.
不要なモデルや定義を作成して開発の時間を無駄にしない事が大事だ。CASEツールメーカーが、特定の機能や特徴を加えたからといって、それを使わなければならないという事はない。これはCASEツールを方法論の代わりに用いる典型的な例である。まず何を作らなければならないか決め、次にそれを作るのにCASEツール使うのである。
Match the selection criteria for the CASE tool to the known characteristics of the planned development effort. This means sizing the tool to the activity. Each tool has built in limitations, and the key is to make sure that based on these missing capabilities, the team does not create an unacceptable manual model transformation activity. Examine the following prior to making a large investment in time with a specific CASE tool:
CASEツールの選択評価基準を、計画中の開発作業の既に判明している特性に合わる。つまり、ツールを作業に照らして評価するという事だ。どのツールにも限界がある。要は、機能不足の為に余計な手作業のモデル変換が起きない様にする事だ。特定のCASEツールに大きな時間をかける前に以下の点を調べると良いだろう。：
View the CASE package as a modeling toolbox, full of many useful SE diagramming, modeling, analysis, specification, and programming tools. Then select the tools which meet the job at hand.
CASEパッケージを、ソフトウェア工学的な図式、モデル化、分析、仕様、プログラミング等のツールが沢山詰まったモデル化のツールボックスと見なす。それから、目の前の仕事に合うツールを選択すれば良い。
Copyright © 1999, Russ Finney, All Rights Reserved
The itmWEB Site・ Copyright © 2006, itmWEB Media Corporation,
All Rights Reserved - webadmin@itmweb.com