The history of software development is a history of raising the level of abstraction. Our industry used to build systems by soldering wires together to form hard-wired programs. Machine code let us store programs by manipulating switches to enter each instruction. Data was stored on drums whose rotation time had to be taken into account so that the head would be able to read the next instruction at exactly the right time. Later, assemblers took on the tedious task of generating sequences of ones and zeroes from a set of mnemonics designed for each hardware platform.
軟件開發的歷史是抽象層次不斷提高的歷史，我們的工業以前是通過將電路焊接在一起以形成硬件組成的程序，這樣來進行系統的搭建。機器碼使得我們可以通過操作開關來輸入每條指令，數據保持在×××××。。。，后來，匯編程序通過為每種硬件平臺定義相應助記符的形式，幫我們把這種繁瑣的0/1操作中解放出來。
At some point, programming languages, such as FORTRAN, were born and "formula translation" became a reality. Standards for COBOL and C enabled portability among hardware platforms, and the profession developed techniques for structuring programs so that they were easier to write, understand, and maintain. We now have languages like Smalltalk, C++, Eiffel, and Java, each with the notion of object-orientation, an approach for structuring data and behavior together into classes and objects.
到了后來，編程語言諸如FORTRAN的出現，使得“公式翻譯”成為現實，COBOL和C標準使得不同硬件平臺之間的移植成為可能，后來發展出了結構化的程序設計方式，使得編程語言更容易編寫、理解和維護。我們現在擁有像smalltalk、C++、Eiffel和Java，它們運用了面向對象技術，一種把數據和行為封裝到類和對象的方法。
As we moved from one language to another, generally we increased the level of abstraction at which the developer operates, which required the developer to learn a new, higher-level language that could then be mapped into lower-level ones, from C++ to C to assembly code to machine code and the hardware. At first, each higher layer of abstraction was introduced only as a concept. The first assembly languages were no doubt invented without the benefit of an (automated) assembler to turn mnemonics into bits, and developers were grouping functions together with the data they encapsulated long before there was any automatic enforcement of the concept. Similarly, the concepts of structured programming were taught before there were structured programming languages in widespread industrial use (for instance, Pascal).
當我們從一種語言發展到另一種語言的時候，通常我們提高了開發者進行開發所處的抽象層次，這需要開發者學習新的、更高層次的能夠映射到低層次的語言，如C++到C到匯編代碼到機器碼和硬件。最初，每一個更高層次的抽象只是作為一個概念被引入。最初的匯編語言被發明的時候，作為把助記符轉換到字節碼的匯編器并沒有體系出什么明顯的又是。。。。，類似的，結構化程序設計的概念也顯得很不為人接受直到結構化編程語言在工業界廣為使用。
Over time, however, the new layers of abstraction became formalized, and tools such as assemblers, preprocessors, and compilers were constructed to support the concepts. This had the effect of hiding the details of the lower layers so that only a few experts (compiler writers, for example) needed to concern themselves with the details of how those layers work. In turn, this raises concerns about the loss of control induced by, for example, eliminating the GOTO statement or writing in a high-level language at a distance from the "real machine." Indeed, sometimes the next level of abstraction has been too big a reach for the profession as a whole, only of interest to academics and purists, and the concepts did not take a large enough mindshare to survive. (ALGOL-68 springs to mind. So does Eiffel, but it has too many living supporters to be a safe choice of example.)
隨著時間的過去，然而，新的抽象層次也開始正式形成，相應的工具如匯編器、預處理器和編譯器開始出現以支持這些概念。它們把低抽象層次的細節隱藏，使得只有少數的專家（如編譯器的編寫者）需要關心這些細節如何工作。。。。。
As the profession has raised the level of abstraction at which developers work, we have developed tools to map from one layer to the next automatically. Developers now write in a high-level language that can be mapped to a lower-level language automatically, instead of writing in the lower-level language that can be mapped to assembly language, just as our predecessors wrote in assembly language and had that translated automatically into machine language.
隨著開發者開發的抽象層次的提高，我們開發出從一個層次自動映射到另一個層次的工具。開發者現在只需編寫高層次的編程語言，之后的轉換將是自動進行的。
Clearly, this forms a pattern: We formalize our knowledge of an application in as high a level a language as we can. Over time, we learn how to use this language and apply a set of conventions for its use. These conventions become formalized and a higher-level language is born that is mapped automatically into the lower-level language. In turn, this next-higher-level language is perceived as low level, and we develop a set of conventions for its use. These newer conventions are then formalized and mapped into the next level down, and so forth.
顯然，這形成了一種模式：我們不斷地提高抽象的層次的概念，隨著時間的過去，我們學會了如何使用這種語言以及應用一系列的使用約束。這些約束變成正式后一種新的語言誕生了，而這種下一代的語言是從低層次被感知的，當我們定義一系列的使用約束之后，這些新的約束又被正式化，來推動下一階段的發展。不斷地循環。
The next level of abstraction is the move, shown in Figure 1-1, to model-based development, in which we build software-platform-independent models.
下一階段的抽象層次在發展，如圖所示。它是基于模型的開發，在這里我們建立的是和軟件平臺無關的模型。
Software-platform independence is analogous to hardware-platform independence. A hardware-platform-independent language, such as C or Java, enables the writing of a specification that can execute on a variety of hardware platforms with no change. Similarly, a software-platform-independent language enables the writing of a specification that can execute on a variety of software platforms, or software architecture designs, with no change. So, a software-platform-independent specification could be mapped to a multiprocessor/multitasking CORBA environment, or a client-server relational database environment, with no change to the model.
軟件平臺無關是和硬件平臺無關類似的概念。一個硬件平臺無關的語言，如C或者Java，可以使得一個規范的編寫能夠在不同的硬件平臺上運行而不需要更改。類似地，一個軟件平臺無關的語言可以使得一個規范的編寫可以在不同的軟件平臺上運行，或者在不同的軟件架構中運行，而不需要更改。因此，一個軟件平臺無關的規范可以映射到多處理器/多任務CORBA環境，或者一個C-S關系數據庫環境，而不需要更改模型。
In general, the organization of the data and processing implied by a conceptual model may not be the same as the organization of the data and processing in implementation. If we consider two concepts, those of "customer" and "account," modeling them as classes using the UML suggests that the software solution should be expressed in terms of software classes named Customer and Account. However, there are many possible software designs that can meet these requirements, many of which are not even object-oriented. Between concept and implementation, an attribute may become a reference; a class may be divided into sets of object instances according to some sorting criteria; classes may be merged or split; statecharts may be flattened, merged, or separated; and so on. A modeling language that enables such mappings is software-platform independent.
總的而言，由概念模型所驅動的數據的組成和處理也許和實際的數據組成和處理不完全相同。如果我們考慮兩個概念，比如“customer”和“Account”，將他們建模程UML的類圖以期望能夠被用。