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

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

前言

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)容概要

本書(shū)從面向?qū)ο蠓缎统霭l(fā)對(duì)軟件工程進(jìn)行重新演繹。全面、系統(tǒng)、清晰地介紹了面向?qū)ο筌浖こ痰幕靖拍睢⒃?、方法和工具，通過(guò)實(shí)例說(shuō)明了面向?qū)ο筌浖_(kāi)發(fā)的整個(gè)過(guò)程。    本書(shū)分為兩個(gè)部分：第一部分介紹了面向?qū)ο筌浖こ痰幕纠碚?；第二部分以工作流的形式介紹了軟件生命周期。

作者簡(jiǎn)介

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

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

圖書(shū)封面

圖書(shū)標(biāo)簽Tags

無(wú)

評(píng)論、評(píng)分、閱讀與下載

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

---

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

---