Preface
序文
　The complexity of most real-time and embedded systems often exceeds that of other types of systems since, in addition to the usual spectrum of problems inherent in software, they need to deal with the complexities of the physical world. That world - as the proverbial Mr. Murphy tells us - is an unpredictable and often unfriendly place. Consequently, there is a very strong motivation to investigate and apply advanced design methods and technologies that could simplify and improve the reliability of real-time software design and implementation.

 　リアルタイムシステムや組み込み型システムの複雑さはほかのシステムの複雑さを超えることがよくあります。これらのシステムはソフトウェア固有のよくある問題範囲に加え、現実世界の複雑性にも対応する必要があります。マーフィー氏はこの世界のことを予測不可能で時には不親切な場所と言っています。従って、リアルタイムソフトウェアの設計や実装における信頼性を向上し、単純化することができる高度な設計方法および技術を利用して研究する非常に強い動機づけがあります。
　As a result, from the first version of UML issued in the mid 1990's, designers of embedded and real-time systems have taken to UML with vigor and enthusiasm. However, the dream of a complete, model-driven design flow from specification through automated, optimized code generation has been difficult to realize without some key improvements in UML semantics and syntax, specifically targeted to the real-time systems problem.

 　その結果、90年代中頃にUML(バージョン1)が出てから、組み込み型システムやリアルタイムシステムの設計者は力と勢いを備えたUMLを好むようになりました。しかし、仕様書からモデル駆動設計フローへの自動化、最適化されたコードの生成はいくつかの重要なUMLの言語(セマンティック・シンタックス)を改良しなければ実現することが困難でした。
　With the enhancements in UML that have been proposed and are near standardization with UML 2.0, many of these improvements have been made. In the Spring of 2003, adoption of a formalized UML 2.0 specification by the members of the Object Management Group (OMG) seems very close. It is therefore very appropriate to review the status of UML as a set of notations for embedded real-time systems - both the state of the art and best practices achieved up to this time with UML of previous generations - and where the changes embodied in the 2.0 specification are taking us.

 　UMLの強化が提案され、改良されたUML2.0が作られました。2003年の春にOMGのメンバーによって、形式化されたUML2.0仕様が採用されたことは非常に緊密になったと思われます。組み込み型リアルタイムシステムの一連の表記法としてUMLを批評することは非常に適しています。それによって、2.0の仕様で具体化された変更点が何かを教えてくれます。
　This book, UML for Real: Design of Embedded Real-Time Systems, was created to provide that survey of UML theory and practice when applied to the real-time systems problems. The book aims to show the reality of UML as a medium for specification and implementation of real-time systems, illustrating both the current capabilities and limits of UML for this task, and future directions that will improve its usefulness for real-time and embedded product design. It also covers selected applications examples. The book is constructed as an edited volume of contributed chapters written by the real experts in this field. Each chapter has extensive references for those readers interested in follow-up reading.

 　この本「UML for Real: Design of Embedded Real-Time Systems」はリアルタイムシステムの問題に適用されたとき、UMLの理論や方法に関する調査にそなえるために作成されました。この本は、現在の性能とこのタスクでのUMLの限界、そしてリアルタイムおよび組み込み型の製品の設計への実用性を向上する今後の方向性を説明し、リアルタイムシステムの仕様および実装の手段として、UMLの実態を明らかにすることを目的としています。それは、選択されたアプリケーションの例も含みます。この本は、この分野のエキスパートによって書かれた多くの寄稿されたチャプタで構成されています。それぞれのチャプタは追求読書に興味のある読者にとって広範囲に参考とするものがあります。
　The first chapter, Models, Software Models and UML, is a short discussion of the role and position of UML in software development in general. This includes a description of how UML is being used in specific application domains - the definition and use of profiles, with in an overall model-driven architecture approach. Chapter 2, UML for Real Time, is an objective critique of UML as a tool for developing real-time software; the advantages that it brings and, more importantly, the difficulties encountered and approaches used to overcome those difficulties.

 　第1章、「Models, Software Models and UML」（モデル、ソフトウェア・モデルおよびUML）は一般的なソフトウェア開発におけるUMLの役割や位置付けといった短い議論です。ここでは、UMLが特定のアプリケーション領域でどのように使われているかの説明が記述されています。第2章、「UML for Real Time」(リアルタイムシステムのUML)はリアルタイムのソフトウェアを開発するためのツールとしてのUMLの客観的な評価(UMLが持つ利点、障害に遭遇した時に問題を打開するアプローチ方法)を述べています。
　The next set of chapters cover how essential real-time concepts and patterns can be represented with UML.. Chapter 3, Structural Modeling with UML 2.0, deals with how UML can be used to model the complex software structures that are typically encountered in large real-time software systems, including structural decomposition and identification of basic logical entities. It is followed by an extensive chapter dealing with the modeling of the dynamics of real-time systems using UML, including the necessary extensions to Sequence Diagrams and other notations. The chapter, Message Sequence Charts, presents the current state of the art concerning MSCs and related notions, such as HMSCs (Hierarchical Message Sequence Charts) and LSCs (Live Sequence Charts), including some proposals for adding object features (in particular classes) and timing constraints.

 　次の章からは本質的なリアルタイムの概念およびパターンはどのようにUMLで表わすことができるのかを取り上げています。第3章、「Structural Modeling with UML 2.0」（UML2.0を用いた構造化モデリング)ではUMLは、基本的で論理的な実態の構造上の分割および識別を含む大規模なリアルタイムソフトウェアシステムで遭遇するような複雑なソフトウェア構造をどのようにモデル化するのかをテーマにしています。シーケンス図形および他の記法に対する必要な拡張を含むUMLを使ったリアルタイムシステムの動的モデリングをテーマとした章が続きます。第4章、「Message Sequence Charts」（メッセージ・シーケンス図）では、オブジェクトの特性やタイミングの制御を加える案を含んだHMSCs (Hierarchical Message Sequence Charts) やLSCs (Live Sequence Charts)のようなMSCや関連した考え方に関する現在の最先端技術を紹介しています。
　We then consider the modeling of common real-time mechanisms and target platforms. Chapter 5, UML and Platform-based Design, covers stereotypes and extensions to notations to represent platform services and their attributes and characteristics as a target for embedded software development. It also presents a design methodology for embedded systems that is fully in accordance with platform-based design principles. The next chapter, UML for Hardware and Software Object Modeling, is based on the HASoC design method for the lifecycle modeling of embedded systems. The object-oriented development technique supports a lifecycle that explicitly separates the behavior of a system from its hardware and software implementation technologies. The methodology emphasizes the reuse of preexisting hardware and software models to ease the development process.

 　その後、私たちは、共通のリアルタイムのメカニズムおよび目標プラットフォームのモデリングを考慮します。第5章、「UML and Platform-based Design」(UMLおよびプラットフォームに基づいた設計)では、組み込み型ソフトウェア開発の目標としてプラットフォーム・サービスおよびそれらの属性や特徴を表わす表記法の定型化、拡張を取り上げています。さらに、プラットフォームに基づいた設計法則に完全に従う、組み込みシステム用の設計方法論を示します。第6章、「UML for Hardware and Software Object Modeling」（ハードウェアおよびソフトウェアオブジェクトモデリングのUML）は、組み込みシステムのライフサイクルモデリングのHASoC設計方法をベースとしています。オブジェクト技術の開発技術は、ハードウェアおよびソフトウェアの実装技術からシステムの挙動を明示的に切り離す、ライフサイクルをサポートします。方法論は、開発プロセスを軽減するために、前から存在しているハードウェアやソフトウェアモデルの再利用を強調しています。
　Chapter 7, Fine-Grained Patterns for Real-time Systems, applies the theory of pattern-based design to the real time world with basic dynamic and static patterns. Chapter 8 then follows with high-level or architectural patterns for modeling real-time software systems, in Architectural Patterns for Real-time systems.

 　第7章、「Fine-Grained Patterns for Real-time Systems」（リアルタイムシステムのきめ細かいパターン）では、基本的な動的・静的なパターンに基づいた設計理論を用いています。第8章、「Architectural Patterns for Real-time systems」（リアルタイムシステムの構造上のパターン)は、リアルタイムソフトウェアのシステムをモデル化するためのハイレベルまたは構造上のパターンに基づいた理論です。
　The next two chapters deal with quantitative modeling concepts. Modeling Quality of Service with UML describes how quantitative aspects can be introduced into UML models; in particular, how quality of service parameters are rendered in the standard real-time UML profile. Modeling Metric Time covers some of the abstract concepts of time modeling and how they are reflected in UML.

 　次の2つの章(第9･10章)は量的モデリングの概念をテーマにしています。第9章、「Modeling Quality of Service with UML」（UMLを用いたモデリングサービスの品質）は、UMLモデルへ定量的な側面をどのように導入できるか、サービス・パラメータの質は標準のリアルタイムのUMLプロフィールでどのように与えられるかを述べています。第10章、「Modeling Metric Time」ではいくつかの時間モデリングの抽象的な概念と、どのようにそれらをUMLに反映するのかを取り上げています。
　Chapter 11, Performance Analysis with UML, covers methods for applying traditional performance analysis techniques to UML models with special focus on the standard real-time UML profile. The next chapter, Schedulability Analysis with UML, applies schedulability theory for real-time systems in the UML context.

 　第11章、「Performance Analysis with UML」（UMLを用いた実行分析）は、標準のリアルタイムのUMLプロフィールで特別な焦点をもつUMLモデルに従来の性能分析技術を適用する方法を取り上げています。第12章、「Schedulability Analysis with UML」UMLのスケジュール分析）では、UMLの文脈でリアルタイムシステムのスケジューリング理論を用いています。
　In the last part of the book we start looking at specific applications. Chapter 13 deals with the application of UML in the automotive domain. Automotive UML includes the structuring of requirements and presents the AML, a modeling language tailored to the development of embedded automotive systems based on the UML.. Chapter 14 and 15, Specifying telecommunications Systems with UML, and Leveraging UML to Deliver Correct Telecom Applications, deal specifically with the specification, design, implementation and verification of telecom systems using UML 2.0.

 　この本の最後の部分で、具体的なアプリケーションを考えています。第13章、「Automotive UML」（自動車のUML）は自動車分野でのUMLの用途について取り上げています。「Automotive UML」は要求の構造化を含み、AML（UMLをベースとした組み込み型自動車システムの開発に適合したモデル化言語）を示します。第14章、「Specifying telecommunications Systems with UML」（UMLを用いた電気通信システム）と第15章、「Leveraging UML to Deliver Correct Telecom Applications」（正確な電気通信アプリケーションを伝えるためのUMLの利用）は、UML2.0を使った電気通信システムの仕様や設計、実装、検証を具体的に取り上げています。
　The last chapter, 16, Software Performance Engineering, illustrates the process of developing real-time systems based on the use of UML and quantitative analysis methods.

 　最後の章である第16章、「Software Performance Engineering」（ソフトウェア実行エンジニアリング）は、UMLと定量分析手法の仕様を基にした、リアルタイムシステムの開発過程を説明します。
　This comprehensive look at the status and applicability of UML to the real-time systems world, on the eve of the UML 2.0 adoption, will be useful to all who wish to find out more about UML, and apply it to the design and development of real products. The authors hope that this collection is one small step on the way to making UML a reality for all software and system designers.

 　これは、UML2.0の採用を前にしたリアルタイムシステムへのUMLのステータスや適用可能性の見直し、UMLについて調べたいと思うすべての人に有用だろう。実際の製品の設計および開発に適用します。著者はこのコレクションがすべてのソフトウェアおよびシステムデザイナにとってUMLの実現に向けてのひとつの小さなステップになることを望みます。
Chapter 1
Models, Software Models and UML

 第１章
モデル・ソフトウェアモデルとUML
Abstract：

 要約：
　The use of models in the design of complex engineering systems is a long?standing tradition that is almost as old as engineering. Yet, its applicability to software has often been questioned. In this chapter, we explain why modeling and model-based techniques are, in fact, the only viable way of coping with the kind of complexity that is encountered in modern software systems (and, in particular, in embedded and real-time systems). The essentials of model-driven development methods are explained and the role that the Unified Modeling Language plays in them is described. The ability to customize UML for such purposes is also covered.

 　複雑なエンジニアリングシステムの設計でのモデルの使用は、エンジニアリングと同じくらい古い、長く続いている伝統的な技法です。しかし、ソフトウェアへの適用可能性はしばしば疑問とされました。本章では、モデリングおよびモデルベースの技術がなぜ現代のソフトウェアシステムで(特に組み込み型リアルタイムシステムで)遭遇する一種の複雑性に対応できる唯一の実行可能な方法なのかを説明します。モデル駆動による開発方法の要点が説明され、その中で統一モデリング言語(UML)が果たす役割について記述されています。そのような目的のUMLをカスタマイズする能力も取り上げられています。
1. ON MODELS

 1. モデルについて
1.1 The Role of Models in Engineering

 1.1 エンジニアリングにおけるモデルの役割
　In 1418 A.D., the guild of wool merchants of Florence announced a competition for a method of constructing the dome that was to cap the magnificent Santa Maria del Fiore cathedral. This presented a unique and very difficult engineering problem. First, the design called for a dome that was bigger than any built up to that time. Second, and even more challenging, this enormous dome was to have no external lateral supports, since the architect had deemed them "inelegant". Such supports, usually in the form of so-called "flying buttresses", served to counter the effects of the significant lateral forces generated by large vertical edifices.

 　西暦1418年、フィレンツェの羊毛商人のギルドは壮大なサンタマリア・デル・フィオーレ大聖堂を凌ぐドームを建設する方法についてのコンペを発表しました。これはユニークで、非常に難しいエンジニアリング問題を提示しました。最初に、ドームのデザインはそれまでに建てたものより大きいものを要求しました。さらに、建築家が外部側面の支柱は美しくないと考えたので、その外部側面に支柱がない巨大ドームを作るように要求した。このような支柱は、通常「飛び梁」といわれる形状で、巨大な垂直建築物に生じる側面にかかる大きな力の影響に対抗する役目を持っています。
　The specifications for the cathedral and its dome were in the form of a scale model, which served to convey design intent to the construction team and also as a feasibility proof (the non-linear effects of scaling up were not fully understood at the time). Accordingly, submitters were asked to provide scale models that would demonstrate the proposed construction method.
 　大聖堂およびドームの仕様書は、建設チームに設計を伝えることと、実現可能性を証明する役目を果たしていたスケールモデル(縮尺模型)の形をしていました。(しかし、拡大する非線形の結果はその時は完全には理解されませんでした。)従って、提出者は提案した建築方法を実証するスケールモデル(縮尺模型)を用意するように依頼されました。
　Perhaps surprisingly, the winning entry did not come from a master mason but from a goldsmith, Philippo Brunelleschi. His model was made out of wood, brick, and mortar and was large enough to allow members of the jury to walk inside and inspect its interior. The most distinguishing and innovative aspect of this proposal was the claim that this dome of unprecedented dimensions was to be constructed without the use of expensive wooden scaffolding to support the vaulted ceiling during construction-even though at its apex the ceiling leaned as much as 30 degrees away from the vertical! Nothing similar had ever been attempted previously on such a scale and it is no understatement to say that the proposal carried a great deal of uncertainty [1].

 　驚いたことに、勝利者は熟練石工からではなく金細工師のフィリッポ・ブルネルスキーが選ばれました。彼のモデルは、木材、レンガ、モルタルで作られ、審査員のメンバーが内側を歩き、内部を調べる十分な大きさがあった。この提案の最も卓越して革新的な特徴は、この前例のない規模のドームの要求を、天井が垂直から30度も傾いたとしても、建設中にアーチ型天井を支える、費用のかかる木製の足場を使用することなく建てることができるということです。類似したものは、このような規模でこれまでに試みられたことはなく、この提案が多くの不確実性を持っていると言うことは決して控えめな表現ではありません。
　Nonetheless, based on the insight and experience gained during the construction of his model, Brunelleschi felt confident and, despite dire warnings from numerous skeptics, he was able to convince the jury that the project was technically feasible. So, the model served not only to demonstrate the proposal to the clients, but also as a testbed for validating a new method of construction. Today, the magnificent dome of Santa Maria del Fiore, still the largest dome ever constructed with bricks and mortar, stands as much a testament to Brunelleschi's ingenuity as to the effectiveness of models in engineering.

 　ブルネレスキーは、モデルの説明中に洞察と経験に基づいて確信を抱き、多くの懐疑論者(反対意見を持つ人)から警告があるにもにもかかわらず、彼はそのプロジェクトが技術的に実現可能であることを審査員に納得させることができました。従って、モデルはクライアントへ提案を示すだけではなく、新しい建築方式の正当性を立証するテストの役目を果たしていました。今日、いまだにレンガとモルタルで建設された最大のドームであるサンタマリア・デル・フィオーレのドームは、エンジニアリングモデルの有効性に関するブルネレスキーの発明を象徴している。
　The use of models for specifying systems is a long-standing engineering tradition that reaches into antiquity. There is evidence that it was a standard practice in Ancient Greece. Vitruvius, a Roman architect who lived in the first century B.C., discusses the use of models in the design of buildings and machinery of various kinds [2]. In the l5th century, Galileo introduced the notion of formal mathematical models that significantly increased the reliability of engineering design.

 　仕様書システムにおけるモデルの使用は大昔からの長年のエンジニアリングの伝統です。それが古代のギリシアの標準の方法だったという証拠があります。ウィトルウィウス(紀元前1世紀に生きていたローマの建築家)は、様々な種類の建物や機械の設計でのモデルの使用について明確にしています。15世紀にガリレオは、エンジニアリング設計の信頼性を著しく増加させた数学モデルの概念を発表しました。
　The main purpose of engineering models is to help us understand the interesting aspects of a complex system before going through the expense and effort of actually constructing it. A good model can help shed light on features of a system where there is uncertainty either about requirements or about the adequacy of a proposed solution particularly where the complexity is such that unaided human reasoning is insufficient.

 　エンジニアリングモデルの主な目的は、実際に構築するための経費や行動を通して、複雑なシステムの、関心をひく特徴を理解することを手助けすることです。必要条件に関してまたは解決案の妥当性に関してはっきりしない場合に、システムの特徴を明確にすることを支援することができます。
　Besides risk mitigation, another fundamental purpose of engineering models is to communicate design ideas to the various parties interested in the system. This includes the many diverse members of the design and construction teams including the patrons for whom the system is being built, as well as the intended users of the system. Of course, different stakeholders may require a different model emphasizing those aspects that are of interest to them. For example, in case of an airplane, the model used by an aerodynamicist is completely different than the one used by the designer of the cabin interior.

 　リスクの軽減に加えて、エンジニアリングモデルの他の基本目的は、システムに興味を持った様々な関係者に設計のアイデアを伝えることです。関係者とは、システムの意図したユーザだけでなく、システムを構築される後援者を含んだ設計と構築のチームのさまざまなメンバーを含みます。もちろん、異なった投資家は彼らの興味がある一面を重要視する異なったモデルを要求するかもしれません。例えば飛行機の場合、空気力学者が利用するモデルは、キャビン内部のデザイナーが利用するモデルとまったく異なります。
1.2 Characteristics of Good Engineering

 1.2 よいエンジニアリングモデルの特徴
　There are a number of key requirements that any good engineering model must fulfill: first, it must support abstraction, that is, it must avoid or hide detail that is irrelevant to the domain of concern. This helps us focus on the important aspects of the problem. Second, it must be expressed in a form (notation, shape) that is close to our intuition, so that we can most easily comprehend it. For example, it is a lot easier to appreciate the esthetic aspects of a proposed building design from a three-dimensional scale model than a corresponding textual description or even a technical drawing. Similarly, a high-level functional block diagram of an electronic circuit is usually much easier to absorb than a corresponding fully-detailed electrical schematic. Third, a good model must be accurate, which means that it must faithfully represent the interesting aspects of the modeled system. Fourth, it should be possible to make accurate predictions about interesting properties of the modeled system from the information provided by the model. Last but not least, a good model must be significantly cheaper to construct or cheaper to experiment with than the actual system. Models that are lacking in any one of these characteristics are likely not to be very suitable as engineering models.

 どんなよいエンジニアリングモデルも満たさなければならない、いくつかの主要な必要条件があります。第１に、モデルは抽象化に対応しなければなりません。つまり、関連領域とは無関係な詳細を無効にするか隠さなければなりません。これは、我々がその問題の重要な側面に注目することを手助けします。第２に、モデルは我々の直感に近い形式(表記法、形態)で表現されなければなりません。その結果、我々は最も容易に理解することができます。例えば、対応する本文の説明や図面より三次元のスケールモデルによって提案される建築設計の芸術的な外観を評価するほうがはるかに簡単です。同様に、ハイレベルな電子回路の機能ブロック図は詳細な電気的図式よりもはるかに理解しやすい。第3に、よいモデルは正確でなければなりません。それはつまり、モデル化されたシステムの関心を引く側面を正確に示さなければならないという意味です。第4に、モデルによって提供される情報から関心のある性質についての正確な予測をすることが可能でなければなりません。最後だが、決して軽んじられないことに、よいモデルは実際のシステムよりも構築・設計するためのコストが安価でなければなりません。これらの特徴のうち1つでも不足しているモデルは、エンジニアリングモデルとして適切とはあまりいえません。
1.3 Models of Software

 1.3 ソフトウェアのモデル
　While the use of models in traditional engineering disciplines is generally accepted as a useful and effective technique, there is still an ongoing debate as to whether it is applicable in the case of software engineering. There are numerous technical and social reasons for this. Regardless of the fact that we know so much about science and engineering in general, software development is an emerging and quite unique discipline that is often applied to systems of unprecedented complexity. Consequently, it still has much of the flavor of a craft about it, reminiscent of the uncertain and mysterious nature characterizing medieval architecture. We still do not know how to construct software systems reliably - at least on the basis of industry statistics to date, which indicate an extremely high rate of failures for software-intensive projects [3].

 　伝統的なエンジニアリング分野でのモデルの使用は、有用で効果的な技術として一般的に認められている一方、それがソフトウェア工学に関して適用可能かどうかの議論は現在も進行中です。これは、多くの技術的または社会的な理由があります。一般的に、我々が科学やエンジニアリングに関して非常によく理解しているという事実に関係なく、ソフトウェア開発は、先例のない複雑なシステムに適用される、新しく類のない分野です。従って、中世の設計概念を特徴づける不確かで不可解な性質によく似ている多くの種類の技術を持っています。我々はまだ、少なくとも産業統計の値(ソフトウェアの集約的なプロジェクトの非常に高い失敗率を示している)に基づいた信頼できるソフトウェアシステムの構築方法を知りません。
　Perhaps the primary reason for this is that - in contrast to traditional forms of engineering where models invariably capture relatively well-understood physical phenomena - a dominant element of all software is applied logic. Unfortunately for us, it is in the nature of logic that even the smallest flaw can render a complex logical construction completely useless. For example, an error in a single statement of a many-thousand-line program resulted in a catastrophic failure of a major part of the North American long-distance telephone network for close to 24 hours [4]. The financial cost of this error from lost business alone was tallied in the hundreds of millions of dollars. If the smallest detail can make a difference, and we have no clear idea which details are crucial in this way, it becomes very difficult to produce trustworthy models of software. And, as we noted earlier, abstraction is a key to successful modeling.

 　この主な理由は、従来の、比較的に汎用的で物理的な現象をとらえるモデルのエンジニアリングの方法とは対照的に、すべてのソフトウェアの主な要素が応用ロジックであるということです。我々にとって不運にも、もっとも最小の欠陥でさえ複雑で論理的な構築を完全に役に立たなくすることはロジックの性質にあります。例えば、数千行のプログラムのたった一つの命令文(ステートメント)のエラーが、北アメリカの長距離電話ネットワークの主要部分に24時間近くの壊滅的な障害を発生させる結果となりました。このエラーの財務費用は失われたビジネスだけで数億ドルと計算されました。もし、最も小さい細部が相違を生じることができ、我々がこのように細部が重要であるという確かな考えを持っていなければ、信頼できるソフトウェアのモデルを作ることは困難になります。前に述べたように、抽象化は成功したモデリングの鍵となるものです。
　Furthermore, much of the initial experience with software modeling has not been encouraging. Software models based on early modeling techniques, such as structured analysis and structured design, often proved to be horribly inaccurate and led to faulty conclusions and a false sense of security. In essence, they failed to meet some of the essential criteria for good models described earlier. The skepticism and even disdain with which many practitioners view software modeling is succinctly expressed by that oft-cited quip by Bertrand Meyer that "bubbles don't crash" [5].

 　さらに、ソフトウェアモデリングの初期の経験は促進されません。構造化分析や構造化設計といったような初期のモデリング技術に基づいたソフトウェアモデルは、恐ろしく不正確であることや、欠陥のある結論や偽りの安全保障につながることがわかりました。要するに、それらは、以前に記述されたよいモデルのいくつかの本質的な基準を満たしていませんでした。ソフトウェアモデリングを考える多くの実行者の懐疑や侮蔑は、バートランド・マイヤーの「泡は衝突しない」というよく引用される皮肉によって簡潔に表現されます。
　However, the situation is not as bleak as such opinions might indicate and models do have an important role to play in the development of software. Moreover, as we shall explain later, it is precisely because software is primarily spun out of non-physical "stuff" that gives software models a unique advantage compared to models in other engineering disciplines.

 　しかし、その状況はそのような意見が示すほど寒々としているわけではなく、モデルはソフトウェア開発で果たすべき重要な役割を持っています。さらに、ソフトウェアは主としてソフトウェアモデルに他のエンジニアリングモデルと比較した独自の利点を与える無形の「要素」によってつむがれるので精密です。
　First, if we genuinely want to construct the kinds of complex systems that we are demanding of our software engineers, we really have no alternative. Most individuals quickly get lost when trying to contemplate too much interlocking detail at once. To quote Dijkstra, "I have a very small head and I had better learn to live with it and respect my limitations" [6]. Our only fundamental solution to dealing with complex problems is to think hierarchically - which is really abstraction. Second, and most fortunate for us, even the most complex logical problems are amenable to this type of approach. Consider, for instance, one of the most complex and most elegant structures in mathematical logic, Godel's proof of the incompleteness theorem [7]. There are numerous examples of high-level outlines (i.e., abstract models) of the extremely complicated proof that describe its essence without going into all the details (see, for example, [7, 8, 9]).

 　第1に、我々がソフトウェアエンジニアに求める、複雑なシステムを真に構築したければ、我々は選択肢を持ちません。あまりに早急に、細部を連結することを考えようとすると、すぐにどうしたらいいのかわからなくなってしまいます。ダイクストラの引用「私は頭が非常に小さい。だから、私はそれを受け入れ、私の制限を尊重することを学んだほうがいい。」複雑な問題に対応するための唯一の根本的な解決法は階層的に考えることです。第2に、我々にとって最も好都合なことに、最も複雑で論理的な問題でさえこのタイプの扱い方に従順です。例えば、数学的論理学、ゲーデルの不完全性定理の証明といった、最も複雑で最も洗練された構造のうちの一つを考察してください。すべての細部に立ち入らずに本質のみ記述した極めて複雑な証明のハイレベルな概要の例が多数あります
　What does a software model look like? We shall illustrate this using the C++ code fragment in Figure 1-1.

 　ソフトウェアモデルはどのようにみえるか?図1-1でC++の断片を使って説明します。
　Note that to understand what this code fragment is doing requires close and thorough inspection and interpretation of practically every token in the text, since the type and placement of syntactic details such as semi-colons, commas, brackets, and braces are all crucial to this understanding.

 　このコード断片が何をしているのかを理解するには、セミコロン、コンマ、カッコ、大カッコのような統語的な詳細記述のタイプや配置を理解することが必要不可欠なので、綿密で完璧なテキスト中のすべてのトークンの検討および解釈を必要とします。
　Next, let us look at the following simple state machine:

 　次に、以下の単純な状態遷移機械を見てみましょう。
　The observant reader may have spotted that this is, in fact, a state-machine representation of the code fragment in Figure 1-2. This representation eliminates much of the syntactical detail of the textual form and, moreover, makes it clear that the example program represents an event-driven application in which the response to an event may depend on previously received events. Finite state machines are a compact, well understood, and widely used graphical formalism for specifying this type of behavior. They are particularly common in real-time systems.

 　観察の鋭い読者なら、図1-2がコード断片を説明した状態遷移機械であることに、気づいたかもしれません。この表現は、テキスト形式の構文の細部をほとんど取り除き、さらに、プログラム例がそれまでに受け入れたイベントによって決まるイベントへの対応をするイベント駆動型のアプリケーションを表していることを明らかにします。有限状態遷移機械は、コンパクトで、非常に理解されやすく、この種の挙動を特定するグラフ形式が広く使われています。それらは、リアルタイムシステムにおいては特に一般的です。
　Therefore, the model in Figure 1-2 fulfills the two primary criteria of successful models: it abstracts out irrelevant detail, and it is expressed in a form that is easily understood. From this we can conclude that a software model is no different in its essentials and its purpose from any other type of engineering model.

 　従って、図1-2のモデルは成功したモデルの２つの主要な基準を満たしています。それは無関係な詳細を取り除き、容易に理解できるような形式で表現されています。これより、我々は、ソフトウェアモデルは他のどの種類のエンジニアリングモデルでも要点や目的が異ならないという結論を下すことができます。
　Nonetheless, there is one quite remarkable difference that the software medium provides that is practically unattainable in any other engineering medium. To understand this, consider Figure 1-3, which represents an evolved version of the same state-machine model after a number of iterations and refinements have been added to the original. These include expanding the simple state, S2, into a composite state with an internal state machine and, possibly, adding more detail on some transition actions (these need not be shown in the high-level model; they are only included here for illustration purposes). Such refinements are typical of the kind of evolution that takes place in an incremental software development process.

 　とはいえ、他のエンジニアリングの手法では事実上実現不可能であることをソフトウェアの手法が提供するという一つの注目すべき相違点があります。このことを理解するために、オリジナルにいくつかの繰り返しと改良を加えた、もとの状態遷移機械モデルの進化したバージョンである図1-3を検討します。これらは、単純な状態のS1を拡張して、S1の内部状態遷移機械や遷移アクションの詳細を加え複合状態にすることを含んでいます。(それらは、説明することを目的としてここに含まれているだけなので、ハイレベルなモデルで示す必要はありません。)このような改良は、追加のソフトウェア開発プロセスで起こる進化の種類としては典型的です。
　Clearly, this type of refinement can be carried on until a complete behavioral specification is obtained -one that includes all the necessary detail required in the final product. This means that we are able to move incrementally from a simplified and highly abstract model of the software to its final fully-specified form without having to change the notation, the implementation medium, the tools, or the method of work! In other words, when it comes to software, it is possible to evolve our models directly into implementations (of course, this presumes that we can automatically generate programs from our models -we shall say more on this later in this chapter). The key advantage of this amazing capability is that it eliminates major error-prone discontinuities -so common in other forms of engineering- that occur when designs are translated into actual implementations. In this case, the design and implementation are one.

 　この種の改良は明らかに、完全な挙動の仕様(最終的な製品に要求された必要な詳細をすべて含むもの)が得られるまで続けることができます。これは、非常に抽象的で単純化された、作業の表記法、実装の手法、ツール、あるいは方法を変更することなく完全に指定される形式のソフトウェアのモデルから増加的に移行することができることを意味しています。言い換えると、それがソフトウェアとなったとき、我々のモデルを直接実装に発展させることが可能です。(もちろん、モデルから自動的にプログラムを生成できると仮定します。)この驚くべき機能の重要な利点は、設計が実際に実装されるときに生じる主要なエラーになりやすい不連続(他のエンジニアリング方式でも共通)を取り除くということです。この場合、設計および実装はひとつです。
　This unique feature of software models has inspired an approach to software development that is sometimes referred to as model-driven development. Perhaps the aspect that most distinguishes model-driven development from traditional software development is that the focus and primary product of development is a model rather than a computer program. Of course, a program is still the ultimate output, but it is derived, usually automatically or semi-automatically, rather than being crafted explicitly.

 　このソフトウェアモデルのユニークな特徴は、モデル駆動開発と呼ばれるソフトウェア開発へのアプローチを思いつかせます。恐らく、従来のソフトウェア開発とモデル駆動開発の相違を示す特徴は、開発の焦点および主要な製品がコンピュータプログラムではなく、モデルであるということです。もちろん、プログラムはまだ根本的な出力であることに変わりはありませんが、明示的に巧妙に作られるのではなく、通常は自動的に、または半自動的に抽出されます。
　Using models to automatically generate programs has long been an objective of many software developers and computer scientists. In effect, this represents a leap to the next generation of computer languages. The technology required to realize this objective has taken a long time to develop, but it has now reached maturity with numerous successful examples of application in large industrial projects [10].

 　自動的にプログラムを生成するためにモデルを使用することは、長い間多くのソフトウェア開発者およびコンピュータ科学者の目標でした。実際に、これは次世代のコンピュータ言語の飛躍を示します。この目的を実現するために必要とする技術は開発に長い時間を費やしました。しかし今、多くの大規模な産業プロジェクトでの適用の成功例がある完成に達しました。
　This maturity has progressed to the stage where the technologies for supporting model-driven development are now being standardized. In particular, this is the objective of the recent initiative announced by the Object Management Group (OMG) called Model-Driven Architecture (MDA) [11]. This is a long-term plan for a series of technology "standards" in support of model-driven development. One of the cornerstones of MDA is the Unified Modeling Language (UML).

 　現在は、この完成によって、モデル駆動開発を支援する技術が標準化されている状況まで前進しました。特に、OMGによって発表されMDAと呼ばれています。これはモデル駆動開発を支える一連の「標準」技術の長期計画です。MDAの基礎のうちの1つはユニファイド・モデリング言語(UML)です。