面向?qū)ο筌浖こ?/h1>

出版時間：2009-3  出版社：機械工業(yè)出版社  作者：Stephen R.Schach  頁數(shù)：558  
Tag標(biāo)簽：無  

前言

The wheel has turned full circle.In 1988, I wrote a textbook entitled Software Engineering. Virtually the only mention of the object-oriented paradigm in that book was one section that described object-oriented design.By 1994, the object-oriented paradigm was starting to gain acceptance in the software industry, so I wrote a textbook called Classical and Object-Oriented Software Engineering. Six years later, however, the object-oriented paradigm had become more important than the classical paradigm. To reflect this change,I switched the order of the two topics in the title of the textbook I wrote in 2000,and called it Object-Oriented and Classical Software Engineering.Nowadays, use of the classical paradigm is largely restricted to maintaining legacy software. Students learn C++ or Java as their first programming language,and object-oriented languages are used in subsequent computer science and computer engineering courses. Students expect that, when they graduate, they will work for a company that uses the object-oriented paradigm. The object-oriented paradigm has all but squeezed out the classical paradigm. And that is why I have written a textbook entitled Object-Oriented Software Engineering.

內(nèi)容概要

本書從面向?qū)ο蠓缎统霭l(fā)對軟件工程進行重新演繹。全面、系統(tǒng)、清晰地介紹了面向?qū)ο筌浖こ痰幕靖拍?、原理、方法和工具，通過實例說明了面向?qū)ο筌浖_發(fā)的整個過程。    本書分為兩個部分：第一部分介紹了面向?qū)ο筌浖こ痰幕纠碚摚坏诙糠忠怨ぷ髁鞯男问浇榻B了軟件生命周期。

作者簡介

（美）沙赫（Stephen R.Schach）1972年獲魏茲曼科學(xué)院物理學(xué)理科碩士學(xué)位，1973年獲開普敦大學(xué)應(yīng)用數(shù)學(xué)博士學(xué)位。目前任教于美國范德比爾特大學(xué)計算機科學(xué)系。他著有多部有關(guān)軟件工程、面向?qū)ο筌浖こ?、面向?qū)ο笙到y(tǒng)分析與設(shè)計的教材。他還在國際上廣泛講授軟件工程方面的

書籍目錄

PARTONE INTRODUCTION TO OBJECT-ORIENTED SOFTwARE ENGINEERING l 　Chapter l The Scope of object-Oriented Software Engineering  　學(xué)習(xí)目標(biāo)　　1.1  Historical Aspects    1.2  Economic Aspects　  1.3  Maintenance Aspects　    1.3.1  The Modern View of Maintenance  9　    1.3.2 The Importance of Post-delivery Maintenance    1.4  Requirements.Analysis.and Design Aspects　  1.5 Team Development Aspects　  1.6  Why There Is No Planning Phase　  1.7  Why There Is No Testing Phase　  1.8  Why There Is No Documentation Phase　  1.9  The Obiect-Oriented Paradigm　  1.10  Terminology　  1.11  Ethical Issues    　Chapter Review　    For Further Reading　    Key Terms    習(xí)題    　References　Chapter 2 Software Life.Cycle Models  　學(xué)習(xí)目標(biāo)  　2.1  Software Development in Theory　  2.2  Winburg Mini Case Study　  2.3  Lessons of the Winburg Mini Case Study　  2.4  Teal Tractors Mini Case Study　  2.5  Iteration and Incrementation　  2.6  Winburg Mini Case Study Revisited　  2.7  Risks and Other Aspects of Iteration and lncrementation　 2.8  Managing Iteration and Incrementation　 2.9  0ther Life—Cycle Models     2.9.1 Code.and.Fix Life-Cycle ModeI     2.9.2  Waterfatf Life-Cycle Modef     2.9.3  Rapid-Prototyping Life-cycle Modef 50     2.9.4  Open-Source Life-Cyle Model     2.9.5  Agile Processes     2.9 6  Synchronize.and.Stabilize Life-Cycle Model     2.9.7  Spiraf Life-Cycle Modef   2.10  Comparison of Life—Cycle Models Chapter Review For Further Reading Key Terms     習(xí)題     References　Chapter 3 The Software Process  　學(xué)習(xí)目標(biāo)  　3.1  The Unified Process　  3.2  Iteration and Incrementation　  3.3  The Requirements Wbrkflow　  3.4  The Analysis workflow　  3.S  The Design Workflow　  3.6  The Implementation Workflow　  3.7  The Test Workflow 78　    3.7.1  Requirements Artfacts　    3.7.2  Analysis Artifacts　    3.7.3  Design Artifacts　    3.7.4  Implementation Artifacts　  3.8  Postdelivery Maintenance　  3.9  Retirement　  3.10  The Phases of the Unifled Process　    3.10.1  The Inception Phase　    3.10.2  The Elaboration Phase　    3.10.3 The Construction Phase　    3.10.4  The Transition Phase　  3.11  0ne-versus Tw0.Dimensional Life-Cycle Models　  3.12  Improving the Software Process　  3.13  Capability Maturity Models　　……PART TWO THE WORKFLOWS OF THE SOFTWARE LIFE CYCLE

章節(jié)摘錄

As explained in Section 3.13, without measurements （or metrics） it is impossible to dettect problems early in the software process, before they get out of hand. In this way, metrics can serve as an early warning system for potential problems. A wide variety of metrics can be used. For example, lines of code （LOC） is one way of measuring the size of a product （see Section 9.2.l）. If LOC measurements are taken at regular intervals, they provide a measure of how fast the project is progressing. In addition, the number of faults per 1000 lines of code is a measure of software quality. After all, it is of little use if a programmer consistently turns out 2000 lines of code a month but half of them have to be thrown away because they are unacceptable. Accordingly, LOC in isolation is not a very meaningful metric.Once the product has been installed on the client's computer, a metric such as mean time between failures provides management an indication of its reliability. If a certain product fails every other day, its quality is clearly lower than that of a similar product that on average runs for 9 months without a failure.Certain metrics can be applied throughout the software process. For example, for each workflow, we can measure the effort in person-months （I person-month is the-amount of work done by one person in 1 month）. Staff turnover is another important metric. High turnover adversely affects current projects because it takes time for a new employee to learn the relevant facts about the project （see Section 4.1）. In addition, new employees may have to be trained in aspects of the software process; if new employees are less educated in software engineering than the individuals they replace, then the process as a whole may suffer. Of course, cost is an essential metric that must also be monitored continually throughout the entire process.A number of different metrics are described in this book. Some are product metrics;they measure some aspect of the product itself, such as its size or its reliability. Others are process metrics used by the developers to deduce information about the software process. A typical metric of this kind is the efficiency of fault detection during development,that is, the ratio of the number of faults detected during development to the total number of faults detected in the product over its lifetime.

編輯推薦

《面向?qū)ο筌浖こ?(英文版)》從面向?qū)ο蠓缎统霭l(fā)對軟件工程進行重新演繹.全面、系統(tǒng)、清晰地介紹了面向?qū)ο筌浖こ痰幕靖拍?、原理、方法和工?通過實例說明了面向?qū)ο筌浖_發(fā)的整個過程?！睹嫦?qū)ο筌浖こ?(英文版)》分為兩個部分：第一部分介紹了面向?qū)ο筌浖こ痰幕纠碚?；第二部分以工作流的形式介紹了軟件生命周期。包括面向?qū)ο笊芷谀Ｐ?、面向?qū)ο蠓治?、面向?qū)ο笤O(shè)計。以及面向?qū)ο筌浖臏y試和維護。討論了文檔、維護、復(fù)用、可移植性、測試和CASEI具等的重要性。包括了能力成熟度模型（CMM）和人員能力成熟度模型（P·CMM）的內(nèi)容。與語言無關(guān)。實例代碼對于C++和Java語言背景的讀者同樣清晰。包括600余篇當(dāng)前熱點研究文章、經(jīng)典文獻(xiàn)和書籍的參考文獻(xiàn)。包含2個用于說明完整軟件生命周期的運行實例，還有7個較小的實例，分別用于突出說明特定的主題?；诮y(tǒng)一過程、Java和C++語言的完整源碼可從作者網(wǎng)站（www.mhhe.com/schach）下載。包括5種類型的習(xí)題。分別是概念理解、項目分析、課程設(shè)計、論文研讀和實例修改。

圖書封面

圖書標(biāo)簽Tags

無

評論、評分、閱讀與下載

• 還沒讀過(58)
• 勉強可看(422)
• 一般般(720)
• 內(nèi)容豐富(2986)
• 強力推薦(244)

---

    面向?qū)ο筌浖こ?PDF格式下載

---