久久久久亚洲av毛片大,香蕉久久夜色精品国产2020,亚洲国产小视频精品久久久三级

The Usability of Open Source Software (ZT)

子弹 — Thu, 14 Aug 2008 05:50:00 GMT

摘要: The Usability of Open Source Software by David M. Nichols and Michael B. TwidaleOpen source communities have successfully developed a great deal of software although most computer users only use propr... 阅读全文

子弹 2008-08-14 13:50 发表评论

Usability 101: Introduction to Usability(ZT)

子弹 — Thu, 14 Aug 2008 05:44:00 GMT

Jakob Nielsen's Alertbox, August 25, 2003:

Usability 101: Introduction to Usability

Summary:
How to define usability? How, when, and where can you improve it? Why should you care? This overview answers these basic questions.

This is the article to give to your boss or anyone else who doesn't have much time, but needs to know the basic usability facts.

What (Definition of Usability)

Usability is a quality attribute that assesses how easy user interfaces are to use. The word "usability" also refers to methods for improving ease-of-use during the design process.

Usability is defined by five quality components:

Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
Efficiency: Once users have learned the design, how quickly can they perform tasks?
Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
Satisfaction: How pleasant is it to use the design?

There are many other important quality attributes. A key one is utility, which refers to the design's functionality: Does it do what users need? Usability and utility are equally important: It matters little that something is easy if it's not what you want. It's also no good if the system can hypothetically do what you want, but you can't make it happen because the user interface is too difficult. To study a design's utility, you can use the same user research methods that improve usability.

Why Usability is Important

On the Web, usability is a necessary condition for survival. If a website is difficult to use, people leave. If the homepage fails to clearly state what a company offers and what users can do on the site, people leave. If users get lost on a website, they leave. If a website's information is hard to read or doesn't answer users' key questions, they leave. Note a pattern here? There's no such thing as a user reading a website manual or otherwise spending much time trying to figure out an interface. There are plenty of other websites available; leaving is the first line of defense when users encounter a difficulty.

The first law of e-commerce is that if users cannot find the product, they cannot buy it either.

For intranets, usability is a matter of employee productivity. Time users waste being lost on your intranet or pondering difficult instructions is money you waste by paying them to be at work without getting work done.

Current best practices call for spending about 10% of a design project's budget on usability. On average, this will more than double a website's desired quality metrics and slightly less than double an intranet's quality metrics. For software and physical products, the improvements are typically smaller �?but still substantial �?when you emphasize usability in the design process.

For internal design projects, think of doubling usability as cutting training budgets in half and doubling the number of transactions employees perform per hour. For external designs, think of doubling sales, doubling the number of registered users or customer leads, or doubling whatever other desired goal motivated your design project.

How to Improve Usability

There are many methods for studying usability, but the most basic and useful is user testing, which has three components:

Get hold of some representative users, such as customers for an e-commerce site or employees for an intranet (in the latter case, they should work outside your department).
Ask the users to perform representative tasks with the design.
Observe what the users do, where they succeed, and where they have difficulties with the user interface. Shut up and let the users do the talking.

It's important to test users individually and let them solve any problems on their own. If you help them or direct their attention to any particular part of the screen, you have contaminated the test results.

To identify a design's most important usability problems, testing five users is typically enough. Rather than run a big, expensive study, it's a better use of resources to run many small tests and revise the design between each one so you can fix the usability flaws as you identify them. Iterative design is the best way to increase the quality of user experience. The more versions and interface ideas you test with users, the better.

User testing is different from focus groups, which are a poor way of evaluating design usability. Focus groups have a place in market research, but to evaluate interaction designs you must closely observe individual users as they perform tasks with the user interface. Listening to what people say is misleading: you have to watch what they actually do.

When to Work on Usability

Usability plays a role in each stage of the design process. The resulting need for multiple studies is one reason I recommend making individual studies fast and cheap. Here are the main steps:

Before starting the new design, test the old design to identify the good parts that you should keep or emphasize, and the bad parts that give users trouble.
Unless you're working on an intranet, test your competitors' designs to get cheap data on a range of alternative interfaces that have similar features to your own. (If you work on an intranet, read the intranet design annuals to learn from other designs.)
Conduct a field study to see how users behave in their natural habitat.
Make paper prototypes of one or more new design ideas and test them. The less time you invest in these design ideas the better, because you'll need to change them all based on the test results.
Refine the design ideas that test best through multiple iterations, gradually moving from low-fidelity prototyping to high-fidelity representations that run on the computer. Test each iteration.
Inspect the design relative to established usability guidelines, whether from your own earlier studies or published research.
Once you decide on and implement the final design, test it again. Subtle usability problems always creep in during implementation.

Don't defer user testing until you have a fully implemented design. If you do, it will be impossible to fix the vast majority of the critical usability problems that the test uncovers. Many of these problems are likely to be structural, and fixing them would require major rearchitecting.

The only way to a high-quality user experience is to start user testing early in the design process and to keep testing every step of the way.

Where to Test

If you run at least one user study per week, it's worth building a dedicated usability laboratory. For most companies, however, it's fine to conduct tests in a conference room or an office �?as long as you can close the door to keep out distractions. What matters is that you get hold of real users and sit with them while they use the design. A notepad is the only equipment you need.

Learn More

My next column will address the main usability misconceptions.

Three-day camp teaching Usability in Practice at the Usability Week 2008 conference in San Francisco (June) and Melbourne (July).

子弹 2008-08-14 13:44 发表评论

Why Free Software has poor usability, and how to improve it(ZT)

子弹 — Thu, 14 Aug 2008 05:40:00 GMT

Why Free Software has poor usability, and how to improve it

When I wrote the first version of this article six years ago, I called it “Why Free Software usability tends to suck”. The best open source applications and operating systems are more usable now than they were then. But this is largely from slow incremental improvements, and low-level competition between projects and distributors. Major problems with the design process itself remain largely unfixed.

Many of these problems are with volunteer software in general, not Free Software in particular. Hobbyist proprietary programs are often hard to use for many of the same reasons. But the easiest way of getting volunteers to contribute to a program is to make it open source. And while thousands of people are now employed in developing Free Software, most of its developers are volunteers. So it’s in Free Software that we see volunteer software’s usability problems most often.

That gives us a clue to our first two problems.

Weak incentives for usability. Proprietary software vendors typically make money by producing software that people want to use. This is a strong incentive to make it more usable. (It doesn’t always work: for example, Microsoft, Apple, and Adobe software sometimes becomes worse but remains dominant through network effects. But it works most of the time.)

With volunteer projects, though, any incentive is much weaker. The number of users rarely makes any financial difference to developers, and with freely redistributable software, it’s near-impossible to count users anyway. There are other incentives �?impressing future employers, or getting your software included in a popular OS �?but they’re rather oblique.
Solutions: Establish more and stronger incentives. For example, annual Free Software design awards could publicize and reward developers for good design. Software distributors could publish statistics on how many of their users use which programs, and how that number is changing over time. A bounty system could let people pay money in escrow for whoever implements a particular usability improvement. And distributed version control could foster quicker competition: distributors could choose not just which application to ship, but also which variant branch of an application, with usability as a factor in their choice.
Few good designers. Some musicians are also great composers, but most aren’t. Some programmers are also great designers, but most aren’t. Programming and human interface design are separate skills, and people good at both are rare. So it’s important for software to have dedicated designers, but few Free Software projects do. Some usability specialists are employed by Free Software vendors such as Mozilla, Sun, Red Hat, and Canonical. But there aren’t many, and skilled volunteer designers are even harder to find.

Solutions: Provide highly accessible training materials for programmers, and volunteer designers, to improve the overall level of design competence. Foster communities that let programmers collaborate with usability specialists. And encourage Free Software projects to have a lead programmer, a lead human interface designer, a help editor, and a QA engineer, these being separate people.

But why is there a shortage of volunteer designers in the first place? That brings us to the third problem.

Design suggestions often aren’t invited or welcomed. Free Software has a long and healthy tradition of “show me the code”. But when someone points out a usability issue, this tradition turns into “patches welcome”, which is unhelpful since most designers aren’t programmers. And it’s not obvious how else usability specialists should help out.

Solution: Establish a process for usability specialists to contribute to a project. For example, the lead designer could publish design specifications on the project’s Web site, and invite feedback on a Weblog, wiki, or mailing list. The designer could respond courteously to design suggestions (even the misguided ones). And the project maintainer could set up an editable issue tracker, instead of an append-only bug tracker �?making it easy to refine, approve or decline, and prioritize implementation of design suggestions in the same way as bug reports.

So why do programmers respond differently to usability suggestions than to more technical bug reports?

Usability is hard to measure. Some qualities of software are easily and precisely measured: whether it runs at all, how fast it starts, how fast it runs, and whether it is technically correct.

But these are only partial substitutes for more important qualities that are harder to measure: whether the software is useful, how responsive it feels, whether it behaves as people expect, what proportion of people succeed in using it, how quickly they can use it, and how satisfied they are when they’re finished.

These human-related qualities can often be measured in user tests. But doing that takes hours or days that volunteers are unwilling to spend. User tests are usually low-resolution, picking up the big problems, but leaving designers without hard evidence to persuade programmers of the small problems. And even once a problem is identified, a solution needs to be designed, and that may need testing too.

Without frequent user testing, volunteer projects rely on subjective feedback from the sort of people devoted enough to be subscribed to a project mailing list. But what these people say may not be representative of even their own actual behavior, let alone the behavior of users in general.

Solutions: Promote small-scale user testing techniques that are practical for volunteers. Develop and promote screen capture, video recording, and other software that makes tests easier to run. Encourage developers to trust user test results more than user opinions. And write design guidelines that give advice on the common small problems that user tests won’t catch.

The lack of dedicated designers, in turn, contributes to three cultural problems in Free Software projects.

Coding before design. Software tends to be much more usable if it is, at least roughly, designed before the code is written. The desired human interface for a program or feature may affect the data model, the choice of algorithms, the order in which operations are performed, the need for threading, the format for storing data on disk, and even the feature set of the program as a whole. But doing all that wireframing and prototyping seems boring, so a programmer often just starts coding �?they’ll worry about the interface later.

But the more code has been written, the harder it is to fix a design problem �?so programmers are more likely not to bother, or to convince themselves it isn’t really a problem. And if they finally fix the interface after version 1.0, existing users will have to relearn it, frustrating them and encouraging them to consider competing programs.

Solution: Pair up designers with those programmers wanting to develop a new project or a new feature. Establish a culture in Free Software of design first, code second.
Too many cooks. In the absence of dedicated designers, many contributors to a project try to contribute to human interface design, regardless of how much they know about the subject. And multiple designers leads to inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.

Solution: Projects could have a lead human interface designer, who fields everyone else’s suggestions, and works with the programmers in deciding what is implementable. And more detailed design specifications and guidelines could help prevent programmer-specific foibles.
Chasing tail-lights. In the absence of a definite design of their own, many developers assume that whatever Microsoft or Apple have done is good design. Sometimes it is, but sometimes it isn’t. In imitating their designs, Free Software developers repeat their mistakes, and ensure that they can never have a better design than the proprietary alternatives.

Solution: Encourage innovative design through awards and other publicity. Update design guidelines, where appropriate, to reflect the results of successful design experiments.

Other reasons for poor usability exist regardless of the presence of dedicated designers. These problems are more difficult to solve.

Scratching their own itch. Volunteer developers work on projects and features they are interested in, which usually means software that they are going to use themselves. Being software developers, they’re also power users. So software that’s supposed to be for general use ends up overly geeky and complicated. And features needed more by new or non-technical users �?such as parental controls, a setup assistant, or the ability to import settings from competing software �?may be neglected or not implemented at all.

Solutions: Establish a culture of simplicity, by praising restrained design and ridiculing complex design. And encourage volunteer programmers to watch their friends and families using the software, inspiring them to fix problems that other people have.
Leaving little things broken. Many of the small details that improve a program’s interface are not exciting or satisfying to work on. Details like setting a window’s most appropriate size and position the first time it opens, focusing the appropriate control by default when a window opens, fine-tuning error messages and other text to be more helpful, or making a progress bar more accurately reflect overall progress. Because these things aren’t exciting or satisfying, often years go by before they get fixed. This gives users a general impression of poor design, and that may in turn discourage usability specialists from contributing.

Solution: When scheduling bug fixes, take into account how long they will take, possibly scheduling minor interface fixes earlier if they can be done quickly. Involve interface designers in this scheduling, to guard against usability flaws being downplayed because “it’s just a UI issue”.
Placating people with options. In any software project with multiple contributors, sometimes they will disagree on a design issue. Where the contributors are employees, usually they’ll continue work even if they disagree with the design. But with volunteers, it’s much more likely that the project maintainer will agree to placate a contributor by adding a configuration setting for the behavior in question. The number, obscurity, and triviality of such preferences ends up confusing ordinary users, while everyone is penalized by the resulting bloat and reduced thoroughness of testing.

Solution: Strong project maintainers and a culture of simplicity. Distributed version control may help relieve the pressure, too, by making it easier for someone to maintain their own variant of the software with the behavior they want.
Fifteen pixels of fame. When a volunteer adds a new feature to a popular application, it is understandable for them to want recognition for that change �?to be able to point to something in the interface and say “I did that”. Sometimes this results in new options or menu items for things that should really have no extra interface. Conversely, removing confusing or unhelpful features may draw the ire of the programmers who first developed them.

Solutions: Provide alternative publicity, such as a Weblog, for crediting contributors. Establish design review of code changes that affect the human interface. Regularly review the entire interface, asking “Do we really need this bit”.
Design is high-bandwidth, the Net is low-bandwidth. Volunteer software projects are usually highly distributed, with contributors in different cities or even different continents. So project communications are mostly plain text, in e-mail, instant messaging, IRC, or a bug tracking system. But interaction design is multi-dimensional, involving the layout and behavior of elements over time, and the organization of those elements in an overall interface.

When developers are in the same room, they can discuss interaction design using whiteboards, paper prototypes, spoken words, and gestures. But on the Internet, these often aren’t available, making discussions much slower and prone to misunderstandings.

Solutions: Develop and promote VoIP, video chat, virtual whiteboard, sketching, and animation software that allows easier communication of design ideas over the Internet. And whenever possible, hold physical meetings for developers to collaborate in person.

Finally, a few problems are specific to Free Software development.

Release early, release often, get stuck. The common practice of “release early, release often” can cause poor design to accumulate. When a pre-release version behaves a particular way, and testers get used to it behaving that way, they will naturally complain when a later pre-release version behaves differently �?even if the new behavior is better overall. This can discourage programmers from improving the interface, and can contribute to the increase in weird configuration settings.

Solution: Publish design specifications as early as possible in the development process, so testers know what to expect eventually.
Mediocrity through modularity. Free software hackers prize code reuse. Often they talk of writing code to perform a function, so that other programmers can write a “front end” (or multiple alternative “front ends”) to let humans actually use it. They consider it important to be able to swap out any layer of the system in favor of alternative implementations.

This is good for the long-term health of a system, because it avoids relying on any single component. But it also leads to a lack of integration which lessens usability, especially if the interfaces between the layers weren’t designed with usability in mind.

For example, most terminal commands do not provide information on how complete a process is, or estimate how much time is remaining. This is traditional behavior in a terminal, but in graphical software, progress feedback is crucial. If a graphical utility is developed merely as a “front end” to the terminal command, it can’t easily provide that feedback.

Solution: Design an example graphical interface first, so that interface requirements for the lower levels are known before they are written.
Gated development communities. When you do anything on a computer system you are relying on software from several different development teams. For example, if you print this Web page to show someone else, that task will involve not just the Web browser, but also a layout engine, a window manager, an interface toolkit, a variety of other libraries, a graphical subsystem, a printing subsystem, a printer driver, a filesystem, and a kernel, almost all of these implemented by separate teams.

Oten these teams don’t communicate with each other frequently. And unlike their proprietary competitors, they nearly all have different release cycles. This makes usability improvements difficult and slow to implement, if those improvements involve coordinating changes across multiple parts of the system.

Solutions: Free Software system vendors can coordinate cross-component features like this, if they have employees working on all relevant levels of the software stack. And volunteer contributors to different software layers can meet at conferences arranged for that purpose.

That’s a long list of problems, but I think they’re all solvable. In the coming months I’ll discuss examples of each of the solutions, and what I’m doing personally to help make Free Software a success.

Email相关协议-SMTP

子弹 — Mon, 11 Aug 2008 01:48:00 GMT

来自�Q?/font>http://www.cnpaf.net/Class/SMTP/

SMTP协议��?/strong>
SMTP被用来在因特�|�上传递电子邮件。文件RFC821规定了该协议的所有细节。但是你只须��C��下面的内容－�Q�该协议的基本命令和�Ҏ��p��了�?br>
　　协议的原理很��单。无非是一个客��L��计算机向服务器发送命令，然后服务器向客户端计��机�q�回一些信息。客房端发送的命��o以及服务器的回应都是字符�Ԍ��你�ƈ不需要特别的软�g��p��d��它们。如果你仔细看过WinsockTerminal�C�Z��E�序的源代码�Q�你��׃��发现�q�一炏V��现在让我们用这个示例程序来向自己发一��电子邮件吧�?br>
　　�q�行�C�Z��E�序�Q�单�?Connect"按钮�Q�在"Connectto..."对话框中输入你的电子邮�g服务器的地址�Q�选择SMTP选项。最后按"Connect"按钮。如果连接成功，Winsock控�g会��生Connected事�g�Q�在状态栏中也可看到连接成功的信息。在��L��本窗口中你将看到从服务器�q�回的文本。该文本包含一个三位数的代码及描述�Q�例如：

　　220-ns.cinfo.ruSendmail8.6.12/8.6.9readyatWed,22Apr199822:54:41+0300
　　220ESMTPspokenhere

　　不必太过留意�q�些描述。因��些描�q�可能会因服务器而异。你只须要知道代码所代表的意思就行了。代�?20表示成功建立�q�接�Q�服务器�{�待你的�W�一个命令�?br>
　　向服务器传递的�W�一个命令是HELO.该命令包含一个参敎ͼ�即你的邮��名�?br>
　　HELOoleg

　　注意:在RFC821中，HELO是一个可选择性命令，如果服务器不要求该命令的话，你可以把它忽略掉�?br>
　　如果命��o成功�Q�服务器会返回一个代码�ؓ250的回应。下一步用MAILFROM命��o告诉服务器你惛_��一��邮件。该命��o以发信�h的邮件地址为参数�?br>
　　MAILFROM:oleg@vbip.com

　　发完命��o后，如果服务器返回一个代码�ؓ250回应�Q�你��可以向服务器发送RCPTTO命��o了。该命��o以收信�h地址为参敎ͼ�一看便知是告诉服务器你惛_��邮�g发到收信人地址处�?br>
　　RCPTTO:somebody@domain.com

　　如果你想��邮件发�l�多个收件�h的话。你需要多�ơ��用RCPTTO命��o�Q�对每个命��o�Q�服务器都会�q�回代码�?50的回应�?br>
　　现在你可以向服务器发送邮件正文了。用DATA命��o告诉服务器以下的内容为邮件正文。在你从服务器收��C��码�ؓ354的回应后�Q�你��可以发送邮件正文了。邮件按行发送，每行邮�g以一个无回�R的换行符�l�束�Q�在VB中就是vbLf�Q�示例程序知道何时��用换行符�Q�何时��用回车加换行�W�。所以你只须按回车键��p��了。下面是一个例子：

　　Subject:Myfirste-mailmessage.

　　　Firstlineofamessage.
　　　Secondline.
　　　.

　　注意上面最后一行的最后一个字�W�是一个小数点。这是正文结束的标志。用VB代码表示��是vbLf&"."&vbCrLf.服务器收到这个标志后�Q�就会立卛_��你返回一个代码�ؓ250的回应以及该邮�g的唯一ID受��?br>
　　250WAA10568Messageacceptedfordelivery

　　��d��完成了，你可以��l�发送下��邮�Ӟ��也可以断开同服务器的连接。如果要断开同服务器的连接就用QUIT命��o。在�q�种情况下，服务器会�q�回一个代码�ؓ221的回应�ƈ断开�q�接�?br>
　　QUIT

　　221ns.cinfo.ruclosingconnection

�Q�－�Q�－�Q�－�Q�－�Q�－�Q?br>SMTP协议是TCP/IP协议族中的一员，主要对如何将电子邮�g从发送方地址传送到接收方地址�Q�也��x��对传输的规则做了规定。SMTP协议的通信模型�q�不复杂�Q�主要工作集中在发送SMTP和接收SMTP上：首先针对用户发出的邮件请求，由发送SMTP建立一条连接到接收SMTP的双工通讯链�\�Q�这里的接收SMTP是相对于发送SMTP而言的，实际上它既可以是最�l�的接收者也可以是中间传送者。发送SMTP负责向接收SMTP发送SMTP命��o�Q�而接收SMTP则负责接收�ƈ反馈应答。可大致用下面的通讯模型�C�意图来表示�Q?br>

�Q�－�Q�－�Q�－�Q?br>SMTP协议原始命��o码和工作原理
1.SMTP是工作在两种情况下：一是电子邮件从客户��Z��输到服务器；二是从某一个服务器传输到另一�?br>服务�?br>2.SMTP是个��h��/响应协议�Q�命令和响应都是��Z��ASCII文本�Q��ƈ以CR和LF�W�结束。响应包括一个表�C��
回状态的三位数字代码
3.SMTP在TCP协议25��L��口监听连接请�?br>4.�q�接和发送过�E�：

a.建立TCP�q�接
b.客户端发送HELO命��o以标识发件�h自己的��n份，然后客户端发送MAIL命��o
服务器端正希望以OK作�ؓ响应�Q�表明准备接�?br>c.客户端发送RCPT命��o�Q�以标识该电子邮件的计划接收人，可以有多个RCPT�?br>服务器端则表�C�是否愿意�ؓ收�g人接受邮�?br>d.协商�l�束�Q�发送邮�Ӟ��用命令DATA发�?br>e.�?表示�l�束输入内容一起发送出�?br>f.�l�束此次发送，用QUIT命��o退出�?br>

5.另外两个命��o�Q?br>VRFY---用于验证�l�定的用户邮��是否存在，以及接收关于该用��L��详细信息�?br>EXPN---用于扩充邮�g列表�?br>
6.邮�g路由�q�程�Q?br>SMTP服务器基�?#8216;域名服务DNS中计划收件�h的域名来路由电子邮�g。SMTP服务器基于DNS中的MX记录
来�\��q��子邮�Ӟ��MX记录注册了域名和相关的SMTP中��L��Q�属于该域的电子邮�g都应向该��L��发送�?br>
若SMTP服务器mail.abc.com收到一��信要发到shuser@sh.abc.com:

a.Sendmail��h��DNS�l�出��L��sh.abc.com的CNAME记录�Q�如有，假若CNAME到shmail.abc.com�Q�则再次
��h��shmail.abc.com的CNAME记录�Q�直到没有�ؓ�?br>b.假定被CNAME到shmail.abc.com,然后sendmail��h��@abc.com域的DNS�l�出shmail.abc.com的MX记录�Q?br>shmailMX5shmail.abc.com
10shmail2.abc.com
c.Sendmail最后请求DNS�l�出shmail.abc.com的A记录�Q�即IP地址�Q�若�q�回��gؓ1.2.3.4
d.Sendmail�?.2.3.4�q�接�Q�传送这��给shuser@sh.abc.com的信�?.2.3.4�q�台服务器的SMTP后台�E�序

7.SMTP基本命��o集：

命��o描述
------------------------------
HELO向服务器标识用户�w�䆾
发送者能�ƺ骗�Q�说谎，但一般情况下服务器都能检��到�?br>
MAIL初始化邮件传�?br>mailfrom:
RCPT标识单个的邮件接收�h�Q�常在MAIL命��o后面
可有多个rcptto:
DATA在单个或多个RCPT命��o后，表示所有的邮�g接收人已标识�Q��ƈ初始化数据传输，�?�l�束�?br>VRFY用于验证指定的用�?邮箱是否存在�Q�由于安全方面的原因�Q�服务器常禁止此命��o
EXPN验证�l�定的邮��列表是否存在，扩充邮箱列表�Q�也常被��用
HELP查询服务器支持什么命�?br>NOOP无操作，服务器应响应OK
QUIT�l�束会话
RSET重置会话�Q�当前传输被取消
--------------------------------

8.MAILFROM命��o中指定的地址是称作envelopefrom地址�Q�不需要和发送者自��q��地址是一致的�?br>RCPTTO与之�{�同�Q�指明的接收者地址�U�Cؓenvelopeto地址�Q�而与实际的to�Q�行是什么无兟�?br>9.��Z��么没有RCPTCC和RCPTBCC
所有的接收者协商都通过RCPTTO命��o来实玎ͼ�如果是BCC�Q�则协商发送后在对�Ҏ��收时被删掉信��接收�?br>10.邮�g被分��Z��部分，信头部分和信体部�?br>envelopefrom,envelopeto与messagefrom:,messageto:完全不相�q�Ӏ?br>evnelope是由服务器主机间SMTP后台提供的，而messagefrom/to是由用户提供的。有无冒号也是区别�?br>
11.怎样�׃��部分检查是否一��信是否是伪造的�Q?br>a.received行的兌��性�?br>现在的SMTP邮�g传输�pȝ��Q�在信封部分除了两端的内部主机处理的之个�Q�考虑两个公司防火墙之�?br>的部分，若两台防火墙机器分别为Ａ和��Q�但接收者检查信��received�Q�行时发现经�q�了C.则是伪造的�?br>b.received�Q�行中的��L��和IP地址�Ҏ��否对应如�Q?br>Receibed:fromgalangal.org(turmeric.com[104.128.23.115]bymail.bieberdorf.edu....
c.被�h手动��d��在最后面的received行：
Received:fromgalangal.org([104.128.23.115])bymail.bieberdorf.edu(8.8.5)
Received:fromlemongrass.orgbygalangal.org(8.7.3)
Received:fromgraprao.combylemongrass.org(8.6.4)
�Q�－�Q�－�Q�－�Q�－
SMTP协议的命令和应答
从前面的通讯模型可以看出SMTP协议在发送SMTP和接收SMTP之间的会话是靠发送SMTP的SMTP命��o和接收SMTP反馈的应�{�来完成的。在通讯链�\建立后，发送SMTP发送MAIL命��o指��o邮�g发送者，若接收SMTP此时可以接收邮�g则作出OK的应�{�，然后发送SMTP�l�箋发出RCPT命��o以确认邮件是否收刎ͼ�如果接收到就作出OK的应�{�，否则��发出拒�l�接收应�{�，但这�q�不会对整个邮�g操作造成影响。双方如此反复多�ơ，直至邮�g处理完毕。SMTP协议共包�?0个SMTP命��o�Q�列表如下：

SMTP命��o命��o说明
HELLO�Q�domain�Q�＜CRLF�Q�识别发送方到接收SMTP的一个HELLO命��o
MAILFROM:�Q�reverse-path�Q�＜CRLF�Q�＜reverse-path�Q��ؓ发送者地址。此命��o告诉接收方一个新邮�g发送的开始，�q�对所有的状态和�~�冲��行初始化。此命��o开始一个邮件传输处理，最�l�完成将邮�g数据传送到一个或多个邮箱中�?br>RCPTTO:�Q�forward-path�Q�＜CRLF�Q�＜forward-path�Q�标识各个邮件接收者的地址
DATA�Q�CRLF�Q?br>接收SMTP��把其后的行为看作邮件数据去处理�Q�以�Q�CRLF�Q?�Q�CRLF�Q�标识数据的�l�尾�?br>REST�Q�CRLF�Q�退�?复位当前的邮件传�?br>NOOP�Q�CRLF�Q�要求接收SMTP仅做OK应答。（用于��试�Q?br>QUIT�Q�CRLF�Q�要求接收SMTP�q�回一个OK应答�q�关闭传输�?br>VRFY�Q�string�Q�＜CRLF�Q�验证指定的邮箱是否存在�Q�由于安全因素，服务器多��止此命令�?br>EXPN�Q�string�Q�＜CRLF�Q�验证给定的邮箱列表是否存在�Q�扩充邮��列表，也常��止使用�?br>HELP�Q�CRLF�Q�查询服务器支持什么命�?br>
注：�Q�CRLF�Q��ؓ回�R、换行，ASCII码分别�ؓ13�?0�Q�十�q�制�Q��?br>
　　SMTP协议的每一个命令都会返回一个应�{�码�Q�应�{�码的每一个数字都是有特定含义的，如第一位数字�ؓ2时表�C�命令成功；�?表失败；3表没有完成。一些较复杂的邮件程序利用该特点�Q�首先检查应�{�码的首数字�Q��ƈ�Ҏ��其值来军_��下一步的动作。下面将SMTP的应�{�码列表如下�Q?br>
应答码说�?br>501参数格式错误
502命��o不可实现
503错误的命令序�?br>504命��o参数不可实现
211�pȝ��状态或�pȝ��帮助响应
214帮助信息
220�Q�domain�Q�服务就�l?br>221�Q�domain�Q�服务关�?br>421�Q�domain�Q�服务未��q�A�Q�关闭传输信�?br>250要求的邮件操作完�?br>251用户非本圎ͼ��{发向�Q�forward-path�Q?br>450要求的邮件操作未完成�Q�邮��׃��可用
550要求的邮件操作未完成�Q�邮��׃��可用
451攑ּ�要求的操作；处理�q�程中出�?br>551用户非本圎ͼ�请尝试＜forward-path�Q?br>452�pȝ��存储不��Q�要求的操作未执�?br>552�q�量的存储分配，要求的操作未执行
553邮箱名不可用�Q�要求的操作未执�?br>354开始邮件输入，�?."�l�束
554操作��p�|
�Q�－�Q�－�Q�－�Q�－

子弹 2008-08-11 09:48 发表评论

Open Source Licenses by Category

子弹 — Mon, 04 Aug 2008 03:57:00 GMT

Open Source Licenses by Category

from: http://www.opensource.org/licenses/category

Tue, 2006-09-19 08:43 �?nelson

.:: License Index ::.

License Approval Process
License Information
Origins and definitions of categories from the License Proliferation Committee report

.:: Licenses that are popular and widely used or with strong communities ::.

*Apache License, 2.0
*New and Simplified BSD licenses
*GNU General Public License (GPL)
*GNU Library or "Lesser" General Public License (LGPL)
*MIT license
*Mozilla Public License 1.1 (MPL)
*Common Development and Distribution License
*Common Public License 1.0
*Eclipse Public License

.:: Special purpose licenses ::.

*Educational Community License
*NASA Open Source Agreement 1.3
*Open Group Test Suite License

.:: Other/Miscellaneous licenses ::.

*Adaptive Public License
*Artistic license 2.0
*Open Software License
*Qt Public License (QPL)
*zlib/libpng license

.:: Licenses that are redundant with more popular licenses ::.

*Academic Free License
*Attribution Assurance Licenses
*Eiffel Forum License V2.0
*Fair License
*Historical Permission Notice and Disclaimer
*Lucent Public License Version 1.02
*University of Illinois/NCSA Open Source License
*X.Net License

.:: Non-reusable licenses ::.

*Apple Public Source License
*Computer Associates Trusted Open Source License 1.1
*CUA Office Public License Version 1.0
*EU DataGrid Software License
*Entessa Public License
*Frameworx License
*IBM Public License
*Motosoto License
*Multics License
*Naumen Public License
*Nethack General Public License
*Nokia Open Source License
* OCLC Research Public License 2.0
*PHP License
*Python license (CNRI Python License)
*Python Software Foundation License
*RealNetworks Public Source License V1.0
*Reciprocal Public License
*Ricoh Source Code Public License
*Sleepycat License
*Sun Public License
*Sybase Open Watcom Public License 1.0
*Vovida Software License v. 1.0
*W3C License
*wxWindows Library License
*Zope Public License

.:: Superseded licenses ::.

*Apache Software License 1.1
*Artistic license 1.0
*Eiffel Forum License V1.0
*Lucent Public License (Plan9)
*Mozilla Public License 1.0 (MPL)

.:: Licenses that have been voluntarily retired ::.

*Intel Open Source License
*Jabber Open Source License
*MITRE Collaborative Virtual Workspace License (CVW License)
*Sun Industry Standards Source License (SISSL)

.:: Uncategorized Licenses ::.

*Affero GNU Public License
*Boost Software License (BSL1.0)
*Common Public Attribution License 1.0 (CPAL)
*GNU General Public License version 3.0 (GPLv3)
*GNU Library or "Lesser" General Public License version 3.0 (LGPLv3)
*ISC License
*Microsoft Public License (Ms-PL)
*Microsoft Reciprocal License (Ms-RL)
*Non-Profit Open Software License 3.0
*NTP License
*Reciprocal Public License 1.5 (RPL1.5)
*Simple Public License 2.0

子弹 2008-08-04 11:57 发表评论

Agile Development [ZT]

子弹 — Mon, 04 Aug 2008 01:18:00 GMT

Agile Development
By John Graham-Cumming

Five Steps to Continuous Integration
Introduction

In this whitepaper I argue that the person most affected by the introduction of agile or extreme programming techniques is not the software or quality assurance engineer, but the build manager. And the build manager can no longer make do with home grown tools; software production automation tools are required to make agile development a build reality.

The reality is that agile techniques are a throwback to the age when developers were able to work on small projects in small teams. Each developer (or sometimes pair of developers) concentrates on small building blocks of code (with associated unit tests), and integrates regularly with other developers to ensure that the overall software project is progressing. For developers, agile techniques are a natural fit because they reflect how developers like to work best: on small, manageable pieces of code with regular feedback.

Even though developers are working on small sections of code, the overall projects they are part of are now very large. So there's no going back to a small build on a single machine for build managers. While developers may have broken their work down into small units that they can code and test, the overall size of most enterprise software projects is constantly growing. And it's the large body of code that the build manager is expected to work with, not the manageable chunks that developers deal with.

In fact, the build manager is expected to cope with ever larger software, on ever more platforms, while at the same time dealing with developers' requests for fast integration builds. Those integration builds enable agile development at the software engineer's desktop because they are able to integrate their local changes into a large build, but cause build managers to be required to produce one or two orders of magnitude more builds per day.

Continuous Integration

To the build manager, the words "multiple integrations per day" and "each integration is verified by an automated build" mean a radical change from once-nightly builds. All these changes are brought about by one central tenet of agile development: continuous integration.

The seminal paper on Continuous Integration (and an excellent, and readable introduction to the topic) is Martin Fowler's article entitled, simply, "Continuous Integration" and is available here.

Its abstract states:

Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

To the build manager, the words "multiple integrations per day" and "each integration is verified by an automated build" mean a radical change from once-nightly builds.

Fowler goes on to list a number of "Practices of Continuous Integration." The first build-related practice is "Automate the Build." He argues that the set of tasks required to go from source code to the final shipping binary is so complex that it should be automated so that it is repeatable. If the build is not automated, he argues, the build process will be error prone.

He also argues that the build includes much more than just compiling the software and building a binary. He sets the goal of, "anyone should be able to bring a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine."

It's worth stopping and thinking about the implications of that statement for your build organization. It's very likely that getting to such an automated stage seems impossible, when starting from what is often a creaky build system held together by a collection of Makefiles, Perl scripts and other programs whose exact function or operation is often unclear.

Clearly, the goal of going from a virgin machine to fully running code is a stretch, but I think it's a good overall goal. Once you reach that stage, you will have put together a build system that is very reliable and should, if written and documented well, be easy to modify and adapt as software changes.

Such a fully automated build has advantages outside the direct realm of agile development. How many times has your build team been asked to rebuild an old version of your software and been unable to do so? Important customers can sometimes demand that old versions of code be patched or updated, or a security problem can mean that all versions of a company's currently supported code need to be fixed and released.

In general, only very well prepared teams are capable of building an arbitrary version of their code. Even if a good archive of the sources was made at the time of release, other components of software are likely to have decomposed: you may not have the right build scripts, or the right compiler, or the right version of some third-party component any more.

Fowler's goal, which I refer to as a "pickled build" (the entire build is pickled in a jar ready for use whenever demanded), done right, means that old versions of software can be rebuilt at will, and helps support developers in their move to agile development.

Fowler's second practice for builds is: "Make Your Build Self- Testing." This implies that the automatic build also includes an automatic test. He asks that any body of code have a set of automatic tests that can check a large part of the code base for bugs. Many developers are, in fact, already writing such test suites through the Extreme Programming focus on unit testing, or by performing Test Driven Development (where developers write the tests before the code).

With this test suite in place, Fowler asks that the automated build test itself by running the test suite and reporting the results. Results would typically be reported on screen or by email if the build and test was run remotely.

Fowler's next two practices have a profound effect on build management: "Everyone Commits Every Day" and "Every Commit Should Build the Mainline on an Integration Machine." The implication is that every developer will be committing code once per day (at least) and that every commit will cause a build and test on some build resource (the "integration machine") managed by the build manager. To put that in perspective, for a team of 20 engineers committing once per day during an 8 hour work day, that's a build and test every 24 minutes. For large teams that number increases, and the time between builds is greatly shorted.

The reason agile developers want these per-commit builds is to ensure that integration between developers is working and that the software being built works, and is testable, at all times. The idea that the software should run at all times is central to agile development, and the health of the per-commit build and test becomes an important sign of health for the entire project. If per-commit builds are done quickly and frequently enough, the build will reflect changes made by a single check-in by a single developer offering unparalleled opportunity to narrow down the cause of a breakage.

In fact, this build is so important that I refer to it as the Agile Heartbeat. Agile teams will install monitoring devices (such as red and green lava lamps) that make the status of the heartbeat build visible to all. Fowler states that no developer should "go home until the mainline build has passed with any commits" they've added. This means that all of engineering looks every day to the heartbeat to measure their own progress (Fowler refers to this in the practice "Everyone can see what's happening").

Another important practice mentioned in Fowler's paper is 'Keep the Build Fast'. This seems like an obvious corollary to the previous practices, since a team that requires a build every few minutes and every time the code changes will necessarily need very fast builds. In fact, Extreme Programming outlines the goal of "ten minute" builds, and I've written previously about what I call espresso builds (builds that only take as long as a coffee break).

Fast builds are also important because developers are looking to the status of the build as a measure of their progress. Every minute that is shaved off the build is a minute saved for all developers who have committed code to that build. With many developers, and many builds, that time saved adds up quickly and fast builds improve the productivity of the entire team.

Fowler suggests that this entire process be either managed by hand (if the team is very small), or through the use of a "continuous integration server." This whitepaper will later describe tools that can be used to implement continuous integration, but first, the very idea of getting to continuous integration may seem daunting. Luckily, it can be broken down into stepping stones that are of a manageable size.

Stepping Stones to Continuous Integration

Although pickling your entire build system (getting the build under ten minutes, building every time a developer checks in and giving automatic feedback) is an enormous task, a stepping stone approach can get you to continuous integration without a single, painful push to change everything in the organization.

And, typically, build managers simply do not have the time or resources to spend on a major change to everything they do. This is especially true when build managers are, naturally, expected to keep churning out the builds that they currently create while improving their processes to meet the needs of agile development.

However, a five-stage approach can help ease the way to continuous integration. Those five stages are: fully automated builds, fast builds, lava lamps, build and test and pre-flight builds. At each stage, the build manager should carefully consider the tool available for automation of the software production process as continuous integration requires a very large effort.

1. Fully Automate

Although some builds are already fully automated, most require integration and agile builds is some manual intervention on the part of the build manager (for the ability to build your example, during the installation of the software when a dialog box software automatically needs clicking). But the core of continuous integration and agile builds is the ability to build your software automatically.

So the first stepping stone is to make the build runnable from a single command invocation (the build manager should simply be able to type build followed by some arguments specifying a particular branch or version of the software to build). Once that build script is in place, the build system should be set to run automatically.

This is mostly a matter of detecting when the source code in the source code management system has changed. One way to do that is to have a simple periodic job that checks for changes. Once changes are detected, the job then waits for the repository to stabilize (to give developers time to commit all their code). The job could then wait for a period of quiet for fifteen minutes following a commit. Once the quiet period has ended, the build system starts a full build and test using the build script to build from the main line of code.

This is probably the only stepping stone that can be performed without resorting to new software production management software. The build script can be written using existing tools (such as GNU Make or Perl), but it's worth looking at available automation tools (open source or commercial) since the detection of source code changes and kicking off of an automated build is a common feature. Getting started with a new tool in a limited way (just for the change detection and build kick off) is a good way to learn the tool without having committed to each of the five steps to continuous integration.

2. Fast Builds

Having automated the build, the next step is to speed up the builds themselves. Although Extreme Programming preaches a ten minute automated build and test, I think that a realistic goal for an existing project is to get the automated build and test under one hour.

With multi-core processors and multi-processor machines becoming commonplace, exploiting parallelism available in builds is a relatively simple way to achieve significant build speed-ups. However, missing or incomplete dependency information makes implementing a homegrown parallel build error-prone…

Getting to fast builds can be hard.

For some projects, it's simply a matter of upgrading from outmoded build hardware to newer machines (and often newer, faster disks since builds require a lot of disk access getting sources and writing objects), but for others the build will either require restructuring (so that it can be broken down into parts runnable on separate machines), or a purpose-built parallel build system will be needed. Parallel build systems are available as both open source and commercial products (including from Electric Cloud). With multi-core processors and multi-processor machines becoming commonplace, exploiting parallelism available in builds is a relatively simple way to achieve significant build speed-ups. However, missing or incomplete dependency information makes implementing a homegrown parallel build error-prone, and requires specialized tools to overcome the inherently serial nature of almost all large build systems.

3. Lava Lamps

Lava lamps (those bubbling colored liquid lamps popular in the 1970s) may seem like a silly way to monitor build progress, and in a physically large team (or with remote teams or a complex project) they may not actually be suitable, but introducing some sort of build monitoring is the third stepping stone. Lava lamps are just a fun, easy-to-implement example of a monitoring system.

A build monitor could be red and green lava lamps, or an internal web page showing live build status, or a flat screen monitor mounted high on the wall giving build status. Introduce a mechanism for build feedback that is clear (red and green for bad and good, for example), easily visible (perhaps those lava lamps are right by the water cooler) and continuously updated.

The build monitor will get its input (good or bad) from the fully automated builds set up in the first stepping stone. Everyone will look to the build monitor first thing in the morning and throughout the day as new builds are run.

Although the build may only run and give feedback a small number of times per day (perhaps as little as four times), the build monitor will start to represent the pulse of the engineering team, illustrating the health of the build and hence the software for all to see. This is another important step towards the goal of every commit initiating a build with results for all to see.

Even with just four builds a day with feedback, developers will be able to identify integration problems much quicker than with a nightly build. And with the automation effort expended in the first stepping stone, these automatic builds will be reliable and repeatable and a good indication of the software's health.

4. Build and Test

If developers are following agile methods, they'll be developing automated test suites using tools like jUnit or cppunit. The third stepping stone is to integrate these tests (and other "smoke tests" that may already exist) into the build system now in place.

This is probably a relatively simple task given that the tests themselves are already automatic. This step is also important because it will raise the visibility and importance of the builds, and becomes the start of the agile heartbeat.

5. Pre-Flight Builds

The primary need of developers practicing agile development is the ability to see that their code integrates with the changes made by other developers. Although they could do this on their local machine (by getting all the relevant sources and running a tool like Make), the integration build may take too long, or need special build resources to be able to construct every part of the software. Typically, that means that developers are forced to limit their builds to small parts of an overall project. Even if developers could run full builds on their machines, the production build environment is often different from the environments on developers’ machines, so a build that works on a developer’s machine may not work in the production environment. Because of these issues, developers frequently introduce errors when they ultimately integrate with the complete system by checking in their code.

A good first step is to put full builds in the hands of developers. The build manager needs to assign a machine (or perhaps more than one if multiple platforms are involved) and set up an internal web page where a developer can request a build.

The developer's request should include their email address, the location of the software they want built (this could be the name of a branch to build, or a directory on a shared server where the developer has placed a personal copy of the source), and the opportunity to determine the extent of the build (for example, the developer could request a build on all platforms, or limit the build to just a single operating system).

The system should maintain a queue (visible through another internal web page) of pending build requests and should handle the builds in first-come, first-served order. When a developer's build has completed running (perhaps a couple of hours after their request), the developer receives an email giving the status of the build and any error output generated by the build system.

In addition, the build system takes the entire output of the build and stores it on a shared disk for the developer to examine. After some fixed period (perhaps a week), the output of the build is automatically deleted by the build system to free up space.

The advantages to the agile developer are immediate: they no longer have to wait for a nightly build (with the inherent 24-hour delay) to determine whether their changes broke anything, and by isolating the build to their sources, or their branch, they are able to much more quickly fix a problem even if their pre-flight build took many hours to complete, because they can narrow down the changed parts of the code more quickly. Furthermore, they can be confident that their check-in will not introduce environment-related build breakages, since the pre-flight build was run in the production environment.

At this point, the entire team can decide to introduce a new rule: no one commits to the mainline of source code control until they've run a successful pre-flight build. Here you've introduced another part of agile development which will greatly reduce the number of errors in the nightly builds. With developers checking their own code against a full build run through the pre-flight system before committing, they ensure that most integration errors are removed before affecting the entire team.

For the team, the great advantage of pre-flight builds is that the nightly or automated builds suddenly become more reliable. If developers are checking their code for breakages against a pre-flight build before checking in, the nightly build's reliability will increase greatly. For the build manager, there are two significant challenges to implementing pre-flight builds: automation and build resource availability.

The first prerequisite of an pre-flight build system is an automatic build, so tackling the first stepping stone is critical. It is, in fact, Fowler's first build-related practice and the cornerstone of continuous integration. The price of getting to a fully automated build (without automated tests at this stage) has to be paid up-front and will be the most expensive (in terms of time) part of the move to continuous integration.

Secondly, the internal web page needs to be written. This is relatively easy with free web servers (such as Apache), and free tools (such as PHP and Perl) being widely available and well documented.

Lastly, as developers start to use the system (and they will if they are trying to be agile), the number of available build machines will become a problem. As many developers begin to ask for preflight builds the build queue may become long (especially if the build time is also long).

At this point, the build manager has achieved agile builds. Developers can build whenever they need to; when code is checked in, it gets built automatically (and quickly) and everyone sees the state of that build. If the build breaks, developers can stop work to get the code integrating quickly.

The build manager may also choose to stop doing nightly builds altogether. With pre-flight and per check-in builds, the nightly build may be a thing of the past.

Tools That Can Help

A good starting point when searching for continuous integration tools is the Wikipedia page entitled "Continuous Integration." There you'll find a long list of commercial and open source tools for building continuous integration servers.

To preserve the team’s sanity and reduce downtime for developers and the build team when looking at tools or considering a build- versus-buy decision, you should aim to change as little as possible about your existing build environment. The goal should be to automate the build completely (so that it can be fired off from a single command) without changing the entire system. All that's needed to get continuous integration off the ground is a single command capable of running an entire build: the command needs to extract the sources from source code management and perform the build.

Once that script is in place, the choice of appropriate tool really comes down to a few key questions:

Does the tool support scheduled builds? If the tool can't support "cron" style builds then it's not worth considering. These are the most basic sort of builds and, even when you've introduced agile development methods, they'll still be important.
Is the tool scalable? One of the characteristics of agile development is that enormous loads will quickly be placed on build resources as engineers start running their own builds. And those resources will be even more stressed when every commit starts a build. Scalability needs to be considered from the start to avoid having to change servers in the middle of the stepping stones to continuous integration. Any tool must scale as resources (such as servers) are added, and be able to make use of pools of resources simultaneously as demand fluctuates throughout the work day. Business demands should be considered as well, as requirements for additional target platforms or integration of new teams will place additional demands upon the system over time.
Does the tool provide reporting or analytical tools? With hundreds of builds per day, managing the output or even just the status of every build is a headache. What was simple with a single nightly build becomes very hard with builds every ten minutes, and it's vital to be able to understand the performance of build systems and how the load and use of the build servers are changing over time.
Is the tool easy to adopt? Avoid any tool that requires rewriting existing Makefiles or build scripts: it's hard enough to adopt a new methodology without being required to start everything from scratch. The tool should work with existing tools and integrate with the existing source code management system.
Will the tool enable pre-flight and per-commit builds? Since these two styles of build are fundamental to continuous integration, the tool must make it easy to integrate with source code management to detect changes to the source base and automatically start builds, and to allow any user to start a build at will.
Does the tool support access control? Since the build servers will now be shared with all of development (and not with the small build team alone), access control is vital to ensure that developers have access to the appropriate resources from any location whether local or remote, and that the build team is able to override running builds to perform high-priority builds at will.
Will the tool support multiple teams or will each group or division require its own investment in a tool (plus configuration and maintenance)? Once automated, many build procedures (such as the job that monitors the source code management system for changes) will likely be generic in nature and easily shared across the organization. To maximize investment in a tool and reduce duplicate work, can common procedures or company standards be rolled out across teams?

In many, if not all cases, a homegrown approach will fall short in one or more of these areas. Or, if the homegrown system is adequate at the outset of the stepping stones to continuous integration, it may fall short over time as the load increases, the number of target platforms increases or as the number of users increases. Commercial tools will also pay off in terms of the reduced administration and maintenance required of a manual setup.

Conclusion

Extreme Programming and Agile Development are being adopted by many software engineering organizations. Achieving agility is not easy, but teams can realize some of the benefits of agile development with a step-by-step approach. Careful planning is required by all parts of the engineering team with a special focus on the build resources. The build team will come under enormous pressure once agile methods are implemented and a step-by-step approach to implementing agile builds is recommended.

Careful selection of appropriate build tools is essential from the start of the roll-out of any agile method. Those tools must be able to cope with the varied demands on the build resources and with the likely growth in the number and size of builds.

Enabling Agile Builds with ElectricCommander

Faster Builds, Automated Tests

To maintain aggressive product release schedules, the LSI Logic Consumer Products engineering team wanted to move toward a daily integration model, integrating, building and testing 25 to 50 unique software builds every 24 hours.

The company first chose Electric Cloud’s ElectricAccelerator to address the build speed issues within the integration model, succeeding in reducing build times by 7-8x (from 150 minutes down to 20-30 minutes).

Seeing success with ElectricAccelerator, LSI decided to convert its test environment to ElectricCommander, Electric Cloud’s production automation solution. Where their previous environment became overloaded handling just 250 concurrent steps, ElectricCommander was able to schedule and execute more than 1,000 concurrent steps with the same hardware setup, dramatically streamlining and speeding the smoke test process.

ElectricCommander is a tool to consider for implementing an agile production process within an enterprise environment. It is a Web-based solution for automating software builds and other production tasks to enable agile, iterative development. Only ElectricCommander is simple enough to use on a small build, yet scalable enough to support the most complex software production environments. It requires minimal process changes to get started or to deploy across teams. It provides the reporting and visibility organizations need for compliance efforts and release planning, plus an unprecedented level of flexibility and customizability to suit the agile organization. For agile teams ElectricCommander enables:

Fast builds: Run multiple procedures in parallel on the same resource, or distribute procedures or individual steps across any number of machines for faster turnaround and more efficient production. For additional speed improvements to the build step, ElectricAccelerator provides a fine-grained parallelism to speed builds by as much as 20x (see below).
Automated and scheduled builds: Schedule production procedures to run at a specified day or time, on an hourly or daily basis, or whenever someone checks in code to a specified repository or branch.
Pre-flight and per-commit builds: The underlying information architecture allows build and release teams to organize production assets into virtual, access-controlled projects, while access to production machines can also be limited or controlled. In this way, a release team can provide developers with dedicated or specified resources for pre-flight builds, as needed. Further, ElectricCommander supports integrations with leading SCM tools to facilitate per-commit builds.
Visibility and reporting: ElectricCommander’s unique analytics provide valuable insight into the details of the build, not just success or failure. The analytics engine extracts information and stores it as persistent properties of the job step, providing easy access to pinpoint statistics and trend reporting.

About Electric Cloud

Electric Cloud is the leading provider of Software Production Management solutions that accelerate, automate and analyze the software development tasks that follow the check-in of new code. These include the software build, package, test and deploy processes.

The reality is that homegrown systems are expensive to maintain and difficult to standardize across an enterprise, and are typically not able to support the frequent iterations at the core of Agile Development. Electric Cloud makes it simple to achieve a scalable, agile software production environment across the organization. Electric Cloud's product suite – ElectricAccelerator, ElectricCommander and ElectricInsight – improves development productivity and product quality by accelerating, automating and analyzing the entire software production management lifecycle. In addition to the ElectricCommander production automation tool, Electric Cloud offers:

ElectricAccelerator

ElectricAccelerator™ accurately executes parallel builds across a cluster of inexpensive servers to reduce build times by as much as 20x. ElectricAccelerator plugs seamlessly into existing build infrastructures, without modifying existing scripts. Faster, more accurate builds dramatically reduce the time developers spend waiting for builds to complete, and enable them to do complete builds before checking in their changes.

ElectricInsight

ElectricInsight™ is a software build visualization tool that, when used in conjunction with ElectricAccelerator, provides job-level detail into parallel builds and provides unprecedented visibility into build results for simplified troubleshooting and performance tuning. Leading companies such as Qualcomm, Intuit, Motorola, and Expedia have trusted Electric Cloud’s Software Production Management solutions to change software builds and the entire production process from a liability to a competitive advantage.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

John Graham-Cumming

John Graham-Cumming is Founder and Chief Scientist at Electric Cloud. Prior to Electric Cloud, John was a Venture Consultant with Accel Partners, VP of Internet Technology at Interwoven, VP of Engineering at Scriptics, and Chief Architect at Optimal Networks. John holds BA and MA degrees in Mathematics and Computation and a Doctorate in Computer Security from Oxford University. John is the creator of GNU Make Standard Library and has six pending patents in the build space.

Electric Cloud, ElectricInsight, ElectricAccelerator, ElectricCommander and Electric Make are trademarks of Electric Cloud. Other company and product names may be trademarks of their respective owners.

Location: United States

子弹 2008-08-04 09:18 发表评论

数独�|�址

子弹 — Fri, 25 Jul 2008 09:33:00 GMT

国内外数独网站推�?/h2>
说明�Q�在此仅列出个�h觉得好的�|�站的地址及介�l�，基本以能够在�U�做题�ؓ主，包括提供技巧讲解等
�q�里介绍的网站只�?span class=t_tag onclick=tagshow(event) href="tag.php?name=%CA%FD%B6%C0">数独的，不包括其他nikoli的逻辑题，虽然下面有些�|�站会涉及到
如果有错误或�~�失�Ƣ迎回帖指正

国内��体中�?→�Ƨ泊颗oubk →�|�址http://sudoku.oubk.com
                        →在线做题主要有各隑ֺ�各规��g��l�数独，锯��数独�Q�GT�Q�数比）�Q�killer数独�Q�GT&killer�Q�对角线数独�Q�对角线>�Q�对角线&killer
                        →有一些新手教�E�包括几个Wing的讲解，初学者比较适用
                        →题目可以打印
                        →开设有论坛提供讨论�Q�论坛地址http://bbs.oubk.com

                        →独数之道|数独爱好�?→�|�址http://www.sudokufans.org.cn
                        →在线做题主要�?7格数独，17��g��刀��数独，51�I�数独，三阶3D数独�Q�四�?D数独�Q�锯齿数独，6×6LED��数�?br>                            6×6GT�Q?×6骰子数独�Q�六角数独（也就是WSC中的star�Q�，四空数独�Q�牡�Ҏ��独，不连�l�数独，17��D��体数�?br>                            八卦数独�Q�无�~�数独，killer数独
                        →有在�U�PK�pȝ��Q�支持多人PK
                        →有数独技巧，数独例题�Q�原创数独，变型数独的文章，技巧篇有一定难度，适合已经掌握初��技巧的独友
                           例题主要采自�q�x��和网友讨论的题目�Q�有一定难度或��味性，变型题来自国内外攉��Q�可以看看新式花�?br>                         →提供可打华ͼ�可导入谜题库�Q�供�|�友下蝲�Q�这里感谢kiwy提供数独大会馆的题库
                        →有传�l�题导入�pȝ��Q�可以把你在别处看到的题导入后在�U�作�{�，�pȝ��会帮助你��查正��?br>
国内�J�体中文 →��怪之�?→�|�址http://oddest.nc.hcc.edu.tw/
                        →有數獨挑戰館數獨大會��?4x4數獨 6x6數獨 ��角數獨離散數獨
                           無��P數獨拒馬數獨字母數獨中央數獨同位數獨城堡數獨愛心數獨三國數獨增區數獨
                           奇數數獨偶數數獨兩儂數獨奇偶數獨同類數獨奇和數獨五十數獨五倍數�?
                        →�E�式�Q�数独大�?br>                         →提供初��技巧的讲解�Q�包括wing�{�的高��技�?br>                         →��怪论坛出了些问题�Q�暂时无法链接，�E�后��d��

国外英文�|�站 →killersudokuonline →�|�址http://www.killersudokuonline.com
                        →每日每周有killer数独�Q�GT数独�Q�GT&killer数独�Q�和oubk的规则有些不同）

                        →英国数独�|�站 →�|�址http://www.sudoku.org.uk/
                        →每日killer数独�Q�传�l�数独，锯��数独

                        →捷克数独�|�站 →�|�址http://www.sudoku-league.com/
                        →提供每日一题（传统数独�Q?br>                         →有PK�pȝ��Q�支持两人PK�Q�可选择easy,middle,hard,brainkiller四种隑ֺ�的传�l�数独题

                        →��x��数独�|�站 →�|�址http://sudoku.com.au/
                        →提供每日一题（传统数独�Q?br>                         →提供技巧讲解，隑ֺ�较高

                        →多�h一题PK�?→�|�址http://www.multiplaysudoku.com
                        →那里的玩家水�q�x��较高�Q�不�q�不用担心你会得零分�Q�因��Z��们会很有�l�士风度的留下几个数让你�?br>
                        →一个数独程式的作者的数独�|?�|�址http://www.djape.net
                        →有传�l�数独，killer数独�Q�锯齿数独，GT数独�Q�武士数独（即五联体数独�Q?br>                         →�|�站提供PDF或TXT源码可以导入他的软�g中游�?br>
                        →又一个数独程式的数独�|?→�|�址http://www.sudocue.net/
                        →提供锯��数独�Q�killer数独�Q�传�l�数独�ؓ主，提供TXT源码可以导入他的游戏软�g�?br>                         →如果你对你的killer数独水��^有信心，那可要尝试一下这里的killer题了

                        →sudoku9981 →�|�址http://www.sudoku9981.com
                        →你一定用�q�他�E�序sudoku9981�Q�也��是中文那个数独博士�Q�不�q�个人支持原装正版，�|�络上可以找到注册码
                        →提供了PDF格式的数独题打印
                        →有各�c�L��巧的讲解�Q�还是比较详�l�的�Q�不论是初学�q�是有基��的都可以学习

                        →Andrew的数独网�?→�|�址http://www.scanraid.com/
                        →传统数独�Q�对角线数独�Q�锯齿数独的解答
                        →各类数独技巧的讲解�Q�适合新手�Q�也适合有一定基��的独�?br>
                        →压��u推荐数独教父的网�?→�|�址http://www.sudoku.com
                        →论坛中有丰富的解题技巧讲解，你可以遇到很多数独高手或数独�E�式高手
                           如果你有一定英文水�q�的话，�l�对能让你的数独水��^上升很多

                        →最后一�?→�|�址http://www.sudokuhints.com/
                        →每天有五道传�l�数独题�Q��Ş状一��P��但是隑ֺ�却不一��P��适合不同阶段的玩�?/font>

[ 本帖最后由叶卡林娜 �?2008-7-4 10:50 �~�辑 ]

www.sudokufans.org.cn独数之道|数独爱好�?我们专注做更好的数独 ��L��的数�?/font>

子弹 2008-07-25 17:33 发表评论

子弹 — Fri, 25 Jul 2008 04:24:00 GMT

UML 序列�?/font>
来自: IBM Rational Edge

　

现在是二月，而且到如今你或许已经��d��、或听到��Z��谈论UML 2.0 —�?包括若干�q�步�?UML 的新规范�Q�所做的变化。考虑到新规范的重要性，我们也正在修改这个文章系列的基础�Q�把我们的注意力�?OMG �?UML 1.4 规范�Q��{�U�d�� OMG 的已采纳 UML 2.0草案规范�Q�又�?UML 2�Q�。我不喜�Ƣ在一�p�d��文章的中��_��把重点从 1.4 变�ؓ 2.0 �Q�但�?UML 2.0 草案规范是前�q�的重要一步，我感觉需要扩充文字�?/em>

�׃��一些理由，OMG 改良�?UML 。主要的理由是，他们希望 UML 模型能够表达模型驱动架构�Q�MDA�Q�，�q�意味着 UML 必须支持更多的模型驱动的�W�号。同�Ӟ�� UML 1.x �W�号集合有时难以适用于较大的应用�E�序。此�?��Z��要��囑֏�成更�Ҏ��阅读�Q�需要改良符号元件。（举例来说�Q�UML 1.x 的模型逻辑��程太复杂，有时不可能完成。对UML 2 中的序列囄��W�号集合的改变，已经在序列化逻辑建模斚w��取得巨大的进�?�?/em>

注意我上面所�q�的文字�Q?#8220;已采�U�UML2.0草案规范�?#8221;��实�Q�规范仍然处于草案状态，但是关键是草案规范已�l�被 OMG 采用�Q�OMG是一个直到新标准相当可靠�Q�才会采用它们的�l�织�?�?UML 2 完全地被采用之前�Q�规范将会有一些修改，但是�q�些改变应该是极��的。主要的改变��会是在 UML 的内�?—�?包括通常被实�?UML 工具的��Y件公�怋�用的功能�?/em>

本文的主要目的是�l�箋把我们的重点攑֜�基础UML图上�Q�这个月�Q�我们进一步了解序列图。再�ơ请注意�Q�下面提供的例子正是以新�?UML 2 规范为基��?/em>

囄��目的
序列图主要用于按照交互发生的一�p�d��序�Q�显�C�对象之间的�q�些交互。很象类图，开发者一般认为序列图只对他们有意义。然而，一个组�l�的业务人员会发玎ͼ�序列图显�C�Z��同的业务对象如何交互�Q�对于交��当前业务如何进行很有用。除记录�l�织的当前事件外�Q�一个业务��的序列图能被当作一个需求文件��用，为实��C��个未来系�l�传递需求。在��目的需求阶�D�，分析师能通过提供一个更加正式层�ơ的表达�Q�把用例带入下一层次。那�U�情况下�Q�用例常常被�l�化��Z��个或者更多的序列图�?/p>
�l�织的技术�h员能发现�Q�序列图在记录一个未来系�l�的行�ؓ应该如何表现中，非常有用。在设计阶段�Q�架构师和开发者能使用图，挖掘出系�l�对象间的交互，�q�样充实整个�pȝ��设计�?/p>
序列囄��主要用途之一�Q�是把用例表辄��需求，转化��一步、更加正式层�ơ的�_��表达。用例常常被�l�化��Z��个或者更多的序列图。序列图除了在设计新�pȝ��斚w��的用途外�Q�它们还能用来记录一个存在系�l�（�U�它�?#8220;遗��”�Q�的对象现在如何交互。当把这个系�l�移交给另一个�h或组�l�时�Q�这个文档很有用�?/p>
�W�号
既然�q�是我基�?UML 2�?UML 囄��列文章的�W�一��，我们需要首先讨论对 UML 2 囄��L��一个补充，即一个叫做框架的�W�号元�g。在 UML 2中，框架元�g用于作�ؓ许多其他的图元�g的一个基��Q�但是大多数人第一�ơ接触框架元件的情况�Q�是作�ؓ囄��囑�Ş化边界。当为图提供囑�Ş化边界时�Q�一个框架元件�ؓ囄��标签提供一致的位置。在 UML 图中框架元�g是可选择的；��如你能在图 1 �?2 中见到的�Q�图的标�{�被攑֜�左上角，在我��调用框架的“namebox”中，一�U�卷角长方�Ş�Q�而且实际�?UML 囑֜�较大的封闭长方�Ş内部定义�?/p>
�?1: �I�的 UML 2 框架元�g

除了提供一个图形化�Ҏ��之外�Q�用于图中的框架元�g也有描述交互的重要的功能, 例如序列图。在序列图上一个序列接收和发送消息（又称交互�Q�，能通过�q�接消息和框架元件边界，建立模型�Q�如�?2 所见到�Q�。这��会在后�?#8220;��越基础”的段落中被更详细��C��l��?/p>

�?2: 一个接收和发送消息的序列�?/span>

注意在图 2 中，对于序列图，囄��标签由文�?#8220;sd”开始。当使用一个框架元件封闭一个图�Ӟ��囄��标签需要按照以下的格式:

囄��?囑֐��U?/code>

UML 规范�l�图�c�d��提供特定的文本倹{��（举例来说�Q�sd代表序列图，activity代表�z�d��图，use case代表用例图）�?/p>
基础
序列囄��主要目的是定义事件序列，产生一些希望的输出。重点不是消息本�w�，而是消息产生的顺序；不过�Q�大多数序列图会表示一个系�l�的对象之间传递的什么消息，以及它们发生的顺序。图按照水��^和垂直的�l�度传递信息：垂直�l�度从上而下表示消息/调用发生的时间序列，而且水��^�l�度从左到右表示消息发送到的对象实例�?/p>
生命�U?/span>
当画一个序列图的时候，攄��生命�U�符号元�Ӟ��横跨囄��剙��。生命线表示序列中，建模的角色或对象实例�?a href="http://www.uml.org.cn/oobject/200503082.htm#notes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">¹生命�U�画作一个方��|��一条虚�U�从上而下�Q�通过底部边界的中心（�?3�Q�。生命线名字攄��在方格里�?/p>

�?3: 用于一个实体名为freshman的生命线的Student�cȝ��一个例�?/span>

UML 的生命线命名标准按照如下格式:

实体�?: �c�d��

在如�?所�C�的例子中，生命�U�表�C�类Student的实体，它的实体名称是freshman。这里注意一点，生命�U�名�U�带下划�Uѝ��当使用下划�U�时�Q�意味着序列图中的生命线代表一个类的特定实体，不是特定�U�类的实体（例如�Q�角�Ԍ��。在��来的一��文章中�Q�我们将会了解结构化建模。现在，仅仅评述序列图，可能包含角色�Q�例�?em xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">买方�?em xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">卖方�Q�，而不需要叙�q�谁扮演那些角色�Q�例�?strong xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Bill�?strong xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Fred�Q�。这准许不同语境的图重复使用。简单拖放，序列囄��实例名称有下划线�Q�而角色名�U�没有�?/p>
�?3 中我们生命线例子是一个命名的对象�Q�但是不是所有的生命�U�K��代表命名的对象。相反的�Q�一个生命线能用来表��C��个匿名的或未命名的实体。当在一个序列图上，��Z��个未命名的实例徏模时�Q�生命线的名字采用和一个命名实例相同的模式�Q�但是生命线名字的位�|�留下空白，而不是提供一个例囑֐�字。再�ơ参考图 3�Q�如果生命线正在表现Student�cȝ��一个匿名例图，生命�U�会�? “Student”。同�? 因�ؓ序列囑֜��目设计阶段中��用，有一个未指定的对象是完全合法: 举例来说�Q?#8220;freshman”�?/p>
消息
��Z��可读性，序列囄��W�一个消息��L��从顶端开始，�q�且一般位于图的左辏V��然后��发的消息加入图中�Q�稍微比前面的消息低些�?/p>
��Z��昄��一个对象（例如�Q�生命线�Q�传递一个消息给另外一个对象，你画一条线指向接收对象�Q�包括一个实心箭��_��如果是一个同步调用操作）或一个棍形箭��_��如果是一个异步讯��P��。消�?�Ҏ��名字攄��在带��头的线上面。正在被传递给接收对象的消息，表示接收对象的类实现的一个操�?�Ҏ��。在�?4 的例子中�Q�analyst对象调用ReportingSystem �cȝ��一个实例的�pȝ��对象。analyst对象在调用系�l�对象的 getAvailableReports �Ҏ��。系�l�对象然后调用secSystem 对象上的、包括参数userId的getSecurityClearance �Ҏ��Q�secSystem的类的类型是 SecuritySystem�?a href="http://www.uml.org.cn/oobject/200503082.htm#notes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">²

�?4: 一个在对象之间传递消息的实例

除了仅仅昄��序列图上的消息调用外�Q�图 4 中的图还包括�q�回消息。这些返回消息是可选择的；一个返回消息画作一个带开攄��头的虚线�Q�向后指向来源的生命�U�，在这条虚�U�上面，你放�|�操作的�q�回倹{��在�?4 中，�?getSecurityClearance �Ҏ��被调用时�Q�secSystem 对象�q�回 userClearance �l�系�l�对象。当 getAvailableReports �Ҏ��被调用时�Q�系�l�对象返�?availableReports�?/p>
此外�Q�返回消息是序列囄��一个可选择部分。返回消息的使用依赖建模的具�?抽象�E�度。如果需要较好的具体化，�q�回消息是有用的�Q�否则，��d��消息��p��够了。我个�h喜欢�Q�无��Z��么时候返回一个��|��都包括一个返回消息，因�ؓ我发现额外的�l�节使一个序列图变得更容易阅诅R�?/p>
当序列图建模�Ӟ��有时候，一个对象将会需要传递一个消息给它本�w�。一个对象何时称它本�w�？一个纯化论者会争辩一个对象应该永不传递一个消息给它本�w�。然而，��Z��递一个消息给它本�w�的对象建模�Q�在一些情境中可能是有用的。�D例来��_��?5 是图 4 的一个改良版本�?�?5 版本昄��调用它的 determineAvailableReports �Ҏ��的系�l�对象。通过表示�pȝ��传递消�?#8220;determineAvailableReports”�l�它本��n�Q�模型把注意力集中到�q�程的事实上�Q�而不是系�l�对象�?/p>
��Z��要画一个调用本�w�的对象�Q�如你��^时所作的�Q�画一条消息，但是不是�q�接它到另外的一个对象，而是你把消息�q�接回对象本�w��?/p>

�?5: �pȝ��对象调用它的 determineAvailableReports �Ҏ��

�?5 中的消息实例昄��同步消息�Q�然而，在序列图中，你也能�ؓ异步消息建模。一个异步消息和一个同步的��L��c�M��Q�但是消息画的线带一个棍形矛��_��如图 6 所�C��?/p>

�?6: 表示传递到实体2的异步消息的序列囄��D?/span>

�U�束
当�ؓ对象的交互徏模时�Q�有时候，必须满��一个条�Ӟ��消息才会传递给对象。约束在 UML 囑֐�处中�Q�用于控制流。在�q�里�Q�我��会讨论UML 1.x 及UML 2.0两者的�U�束。在 UML 1.x 中，一个约束只可能被分配到一个单一消息。UML 1.x中，��Z��在一个序列图上画一个约束，你把�U�束元�g攑֜��U�束的消息线上，消息名字之前。图 7 昄��序列囄��一个片�D�，消息addStudent �Ҏ��上有一个约束�?/p>

�?7:UML 1.x 序列囄��一个片�D�，其中addStudent 消息有一个约�?/span>

在图 7 中，�U�束是文�?#8220;[ pastDueBalance=0]”。通过�q�个消息上的�U�束�Q�如果应收帐�pȝ��q�回一个零点的逾期�q��Q�addStudent 消息才将会被传递。约束的�W�号很简单；格式�?

[Boolean Test]

举例来说�Q?/p>

[pastDueBalance = 0]

�l�合��片(变体�Ҏ��Q�选择��，和��@�?
然而，在大多数的序列图中，UML 1.x“in-line”�U�束不��以处理一个徏模序列的必需逻辑。这个功能缺失是 UML 1.x 的一个问题。UML 2 已经通过��L��“in-line”�U�束�Q�增加一个叫做组合碎片的�W�号元�g�Q�解决了�q�一个问题。一个组合碎片用来把一套消息组合在一��P��在一个序列图中显�C�条件分支。UML 2 规范指明了组合碎片的 11 �U�交互类型。十一�U�中的三�U�将会在“基础”�D�落中介�l�，另外两种�c�d��会�?#8220;��越基础”中介�l�，而那剩余的六�U�我��会留在另一��文章中介绍。（嗨，�q�是一��文章而不是一本书。我希望你在一天中看完�q�部分！�Q?/p>
变体
变体用来指明在两个或更多的消息序列之间的、互斥的选择�?a href="http://www.uml.org.cn/oobject/200503082.htm#notes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">³变体支持�l�典�?#8220;if then else”逻辑的徏模（举例来说�Q?strong xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">如果我买三个�Q?strong xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">然后我得�?我购买的20% 折扣�Q?strong xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">否则我得到我购买�?10% 折扣�Q��?/p>
��如你将会在�?8 中注意到的，一个变体的�l�合��片元�g使用框架来画。单�?#8220;alt”攄��在框架的namebox里。然后较大的长方形分�?UML 2 所�U�的操作元�?a href="http://www.uml.org.cn/oobject/200503082.htm#notes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">⁴操作元被虚线分开。每个操作元有一个约束进行测试，而这个约束被攄��在生命线��端的操作元的左上部�?a href="http://www.uml.org.cn/oobject/200503082.htm#notes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">⁵如果操作元的�U�束�{�于“true”�Q�然后那个操作元是要执行的操作元�?/p>

�?8�Q�包含变体组合碎片的一个序列图片段

�?8作�ؓ一个变体的�l�合��片如何阅读的例子，昄��序列从顶部开始，即bank对象获取支票金额和帐��L��余。此�Ӟ��序列图中的变体组合碎片接��。因为约�?#8220;[balance >= amount]”�Q�如果余额超�q�或�{�于金额�Q�然后顺序进行bank对象传�?addDebitTransaction �?storePhotoOfCheck 消息�l�account对象。然而，如果余额不是��过或等于金额，然后��序的过�E�就是bank传递addInsuffientFundFee �?noteReturnedCheck 消息�l�account对象�Q�returnCheck 消息�l�它自��n。因�?#8220;else”�U�束�Q�当余额不大于或者等于金额时�Q�第二个序列被调用。在变体的组合碎片中�Q�不需�?#8220;else”�U�束�Q�而如果一个操作元�Q�在它上面没有一个明��的�U�束�Q�那么将假定“else”�U�束�?/p> 变体的组合碎片没被限制在��单的“if then else”验证。可能需要大量的变体路径�?如果需要较多的变体�Ҏ��Q�你一定要做的全部工作��是把一个操作元加入有序列约束和消息的长方�Ş中�?
选择��?/span>
选择��组合碎片用来�ؓ序列建模�Q�这些序列给予一个特定条�Ӟ��会发生的；或者，序列不发生。一个选择��用来�ؓ��单的“if then”表达式徏模。（例如�Q�如果架上的圈饼��于五个�Q�那么另外做两打圈饼�Q��?/p>
选择��组合碎片符号与变体�l�合��片�c�M��Q�除了它只有一个操作元�q�且�怸�能有“else”�U�束以外�Q�它��是如此�Q�没有理由）。要画选择��组合，你画一个框架。文�?#8220;opt”是被攄��在框架的 namebox 里的文本�Q�在框架的内容区�Q�选择��的�U�束被放�|�在生命�U�K��端上的左上角�?然后选择��的消息序列被放在框架的内容区的其余位置内。这些元件如�?9 所�C��?/p>

�?9�Q�包括选择��组合碎片的一个序列图片段

阅读选择��组合碎片很�Ҏ��。图 9 是图 7 的序列图片段的再加工�Q�但是这�ơ它使用一个选择��组合碎片，因�ؓ如果Student的逾期�q��{�于0�Q�需要传递更多的消息。按照图 9 的序列图�Q�如果Student的逾期�q��{�于�Ӟ��然后传递addStudent�Q�getCostOfClass和chargeForClass消息。如果Student的逾期�q��不等于零�Q�那么在选择��组合碎片中�Q�序列不传递�Q何一个消息�?/p>
例子�?9的序列图片段包括一个选择��约束；然而，�U�束不是一个必需的元件。在高层�ơ、抽象的序列图中�Q�你可能不想叙述选择��的条�g。你可能只是惌��指出片段是可选择的�?/p>
循环
有时候你��会需要�ؓ一个重复的序列建模。在 UML 2 中，��Z��个重复的序列建模已经改良�Q�附加了循环�l�合��片�?/p>
循环�l�合��片表面非常�c�M��选择��组合碎片。你��M��个框�Ӟ��在框架的 namebox 中放�|�文�?#8220;loop”。在框架的内容区中，一个生命线的顶部，循环�U�束⁶被放�|�在左上角。然后��@环的消息序列被放在框架内容区的其余部分中。在一个��@环中�Q�除了标准的布尔��试外，一个约束能��试二个特定的条件式。特定的�U�束条�g式是写作“minint = [the number]”�Q�例如，“minint = 1”�Q�的最��@环次敎ͼ�和写�?#8220;maxint = [the number]”�Q�例如，“maxint = 5”�Q�的最大��@环次数。通过最��@环检验，循环必须�q�行臛_��指定�ơ数�Q�而��@环执行次��C��能达到约束指定的最大��@环次数�?/p>

�?10�Q��@环组合碎片的一个序列图例子 �Q�单��L��大）

在图 10 中显�C�的循环�q�行�Q�直�?reportsEnu 对象�?hasAnotherReport 消息�q�回false。如果��@环序列应该运行，�q�个序列囄��循环使用一个布��测试确认。�ؓ了阅读这个图�Q�你和��^�怸��P��从顶部开始。当你到辑��@环组合碎片，做一个测试，看看�?hasAnotherReport 是否�{�于true。如�?hasAnotherReport 值等于true�Q�于是序列进入��@环片断。然后你能和正常情况一��P��在序列图中跟�t��@环的消息�?/p>
��越基础
我已�l�介�l�了序列囄��基础�Q�应该��你可以�ؓ��会在系�l�中通常发生的大部䆾交互建模。下面段落将会介�l�用于序列图的比较高阶的�W�号元�g�?
引用另外一个序列图
当做序列囄��时候，开发者爱在他们的序列图中�Q�重用存在的序列图�?a href="http://www.uml.org.cn/oobject/200503082.htm#notes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">⁷�?UML 2 中开始，引进“交互�q�行”元�g。追加交互进行的可以说是 UML 2 交互建模中的最重要的创新。交互进行增加了功能�Q�把原始的序列图�l�织成�ؓ复杂的序列图。由于这些，你能�l�合�Q�重用）较简单的序列�Q�生成比较复杂的序列。这意味你能把完整的、可能比较复杂的序列�Q�抽象�ؓ一个单一的概念单位�?/p>
一个交互进行元件��用一个框架绘制。文�?#8220;ref”攄��在框架的 namebox 中，引用的序列图名字攄��在框架的内容区里�Q�连同序列图的�Q何参��C��赗��引用序列图的名字符号如下模�?

序列囑֐�[(参数)] [: �q�回值]

两个例子:

1. Retrieve Borrower Credit Report(ssn) : borrowerCreditReport

或�?/p>
2. Process Credit Card(name, number, expirationDate, amount : 100)

在例�?1 中，语法调用叫做Retrieve Borrower Credit Report的序列图�Q�传递给它参�?ssn。序列Retreive Borrower Credit Report�q�回变量 borrowerCreditReport �?/p>
在实�?2 中，语法调用叫做Process Credit Card的序列图�Q�传递给它参数name�Q�number�Q�expiration date�Q�和 amount。然而，在例�?2 中，amount参数��会是�?00。因��Z��?没有�q�回值标�{�，序列不返回��|��假设�Q�徏模的序列不需要返回��|��?/p>

�?11: 一个引用两个不同序列图的序列图

�?11 昄��一个序列图�Q�它引用了序列图“Balance Lookup”�?#8220;Debit Account”。序列从左上角开始，客户传递一个消息给teller对象。teller对象传递一个消息给 theirBank 对象。那�Ӟ��调用Balance Lookup序列图，�?accountNumber作�ؓ一个参��C��递。Balance Lookup序列图返回balance变量。然后检验选择��组合碎片的�U�束条�g�Q�确认余额大于金额变量。在余额比金额更大的情况下，调用Debit Account序列图，�l�它传递参数accountNumber 和amount。在那个序列完成后，withdrawCash 消息为客戯��回cash�?/p>
重要的是�Q�注意在�?11 中，theirBank 的生命线被交互进行Balance Lookup隐藏了。因��Z��互进行隐藏生命线�Q�意味着theirBank 生命�U�在“Balance Lookup”序列图中被引用。除了隐藏交互进行的生命�U�之外，UML 2 也指明，生命�U�在它自��q��“Balance Lookup”序列中，一定有相同�?theirBank �?/p>
有时候，你�ؓ一个序列图建模�Q�其中交互进行会重叠没有在交互进行中引用的生命线。在那种情况下，生命�U�和正常的生命线一��h��C�，不会被重叠的交互�q�行隐藏�?/p>
在图 11 中，序列引用“Balance Lookup”序列图�?#8220;Balance Lookup”序列囑֜��?12 中显�C�。因��Z��子序列有参数和一个返回��|��它的标签 —�?位于囄�� namebox �?—�?按照一个特定模�?

囄��?囑֐� [参数�c�d��:参数名]

[: �q�回值类型]

两个例子:

1. SD Balance Lookup(Integer : accountNumber) : Real

�?/p>
2. SD Available Reports(Financial Analyst : analyst) : Reports

�?12 举例说明例子 1�Q�在里面�Q�Balance Lookup序列把参�?accountNumber 作�ؓ序列中的变量使用�Q�序列图昄��q�回的Real对象。在�c�M��q�种情况下，�q�回的对象采用序列图实体名�?/p>

�?12: 一个��?accountNumber 参数�q�返回一个Real对象的序列图

�?13 举例说明例子 2�Q�在里面�Q�一个序列图获取一个参敎ͼ��q�回一个对象。然而，在图 13 中参数在序列的交互中使用�?/p>

�?13: 一个在它的交互中��用参数、返回一个Reports对象的序列图

�?/span>
前面的段落展�C�如何通过参数和返回��g��递信息，引用另一个序列图。然而，有另一个方法在序列图之间传递消息。门可能是一个容易的�Ҏ��Q��ؓ在序列图和它的上下文之间的传递消息徏模。一个门只是一个消息，囑�Ş表示��Z��端连接序列图的框架边�~�，另一端连接到生命�Uѝ��用门的图 11 �?12 �Q�在�?14 �?15 中可以被看到重构。图 15 的例图有一个叫做getBalance的入口门�Q�获取参�?accountNumber。因为是��头的线�q�接到图的框�Ӟ��而箭头连接到生命�U�，所�?getBalance 消息是一个入口门。序列图也有一个出囗门�Q�返回balance变量。出口门同理可知�Q�因为它是一个返回消息，�q�接从一个生命线到图的框�Ӟ��头�q�接框架�?/p>

�?14: �?11 的重构，�q�次使用�?/span>

�?15: �?12 的重构，�q�次使用�?/span>

�l�合��片�Q�蟩转和�q�行�Q?/span>
在本文前�?#8220;基础”的段落中呈现的，我介�l�了“变体”�Q?#8220;选择��?#8221;�Q�和“循环”的组合碎片。这些三个组合碎片是大多��C�h��会使用最多的。然而，有二个其他的�l�合��片�Q�大量共享的人将会发现有用——蟩转和�q�行�?/p>
跌��{
跌��{�l�合��片几乎在每个方面都和选择��组合碎片一��_��除了两个例外。首先，跌��{的框架namebox的文�?#8220;break”代替�?#8220;option”。其��? 当一个蟩转组合碎片的消息�q�行�Ӟ��闭的交互作用的其他消息��不会执行，因�ؓ序列打破了封闭的交互。这��P��跌��{�l�合��片非常�?C++ �?Java 的编�E�语�a�中的break关键字�?/p>

�?16: 来自�?8 的序列图片段的重构，片段使用跌��{代替变体

跌��{最常用来做模型异常处理。图 16 是图 8 的重构，但是�q�次�?6使用跌��{�l�合��片�Q�因为它把balance < amount的情况作��Z��个异常对待，而不是一个变体流。要阅读�?16�Q�你从序列的左上角开始，向下诅R��当序列到达�q�回�?#8220;balance”的时候，它检查看看是否余额比金额更少。如果余额不��于金额�Q�被传递的下一个消息是 addDebitTransaction 消息�Q�而且序列正常�l�箋。然而，在余额比金额更少的情况下�Q�然后序列进入蟩转组合碎片，它的消息被传递。一旦蟩转组合的消息的已�l�被传递，序列不发送�Q何其它消息就退出（举例来说�Q�addDebitTransaction�Q��?/p>
注意有关跌��{的一仉��要的事是�Q�它们只引�v一个封闭交互的序列退出，不必完成图中描述的序列。在�q�种情况下，跌��{�l�合是变体或者��@环的一部分�Q�然后只是变体或循环被退出�?/p>
�q�行
今天的现代计��机�pȝ��在复杂性和有时执行�q�发��d��斚w��不断�q�步。当完成一个复杂�Q务需要的处理旉��比希望的长的时候，一些系�l�采用�ƈ行处理进�E�的各部分。当创造一个序列图�Q�显�C��ƈ行处理活动的时候，需要��用�ƈ行组合碎片元件�?/p>
�q�行�l�合��片使用一个框架来画，你把文本“par”攑֜�框架�?namebox 中。然后你把框架的内容�D는�虚线分�ؓ水��^操作元。框架的每个操作元表�C�Z��个在�q�行�q�行的线�E��?/p>

�?17: oven 是�ƈ行做两个��d��的对象实�?/span>

�?17 可能没有举例说明做�ƈ行活动的对象的最好的计算机系�l�实例，不过提供了一个容易理解的�q�行�z�d��序列的例子。序列如�q�样�q�行�Q�hungryPerson 传�?cookFood 消息�l�oven 对象。当oven 对象接收那个消息�Ӟ��它同时发送两个消息（nukeFood �?rotateFood�Q�给它本�w�。这些消息都处理后，hungryPerson 对象从oven 对象�q�回 yummyFood �?/p>
�ȝ��
序列图是一个用来记录系�l�需求，和整理系�l�设计的好图。序列图是如此好用的理由是，因�ؓ它按照交互发生的旉��序�Q�显�C�Z��pȝ��中对象间的交互逻辑�?/p>
参�?/span>

UML 2.0 Superstructure Final Adopted Specification (�W?章部�? http://www.omg.org/cgi-bin/doc?ptc/2003-08-02
UML 2 Sequence Diagram Overview http://www.agilemodeling.com/artifacts/sequenceDiagram.htm
UML 2 Tutorial http://www.omg.org/news/meetings/workshops/UML%202003%20Manual/Tutorial7-Hogg.pdf

脚注
1 在完全徏模系�l�中�Q�对象（�cȝ��实例�Q�也��会在系�l�的�c�d��中徏模�?/p>
2 当阅读这个序列图�Ӟ��假定分析师登录进入系�l�之内�?/p>
3 ��h��意，附着在不同的变体操作元上的、两个或更多的约束条件式的确可能同时是真�Q�但是实际最多只有一个操作元��会在运行时发生�Q�那�U�情况下变体�?#8220;wins”没有按照 UML 标准定义)�?/p>
4 虽然操作元看��h��非常象公路上的小路，但是我特别不叫它们小路。泳道是在活动图上��用的 UML �W�号。请参�?em xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">The Rational Edge 早期关于 �z�d��囄��文章�?/p>
5 通常�Q�附上约束的生命�U�是拥有包含在约束表辑ּ�中的变量的生命线�?/p>
6 关于选择��组合碎片，循环�l�合��片不需要在它上攄��一个约束条件�?/p>
7 可能重用��M��c�d��的序列图�Q��D例来��_��E�序或业务）。我只是发现开发者更喜欢按功能分解他们的图�?/p>
参考资�?/span>

您可以参阅本文在 developerWorks 全球站点上的英文原文�?br>

　

关于作�?br>Donald Bell是IBM全球服务的一个IT专家�Q�在那儿他和IBM的客户一赯��力于设计和开发基于��Y件解��x��案的J2EE�?/span>

子弹 2008-07-25 12:24 发表评论

好书列表[ZT]

子弹 — Mon, 21 Jul 2008 06:56:00 GMT

以下内容来自�Q?a href="http://www.umlchina.com/book/book.htm">http://www.umlchina.com/book/book.htm

*以下是现在这个时候首选阅�ȝ��国内出版书籍�Q�这些书已经�q�UMLChina专家购买阅读之后才会郑重推荐�Q�选择仅代表UMLChina观点�?br>*本列表会不定时更斎ͼ�每次更新都会向列表里增加一些新书，也删��M��些老书�Q�被删去的原因可能是随时间的淘汰�Q�也可能是我们对�q�些书有了新的认识�?/p>
《修改代码的艺术�?/a>�Q�Michael Feathers 著，刘未�?译，人民邮电出版�C�，2007�?/font>
《UML嵌入式设计�?/a>�Q�高焕堂著， UMLChina改编�Q�清华大学出版社�Q?008�?/font>
《Head First 设计模式�?/a>�Q�Eric Freeman, Elisabeth Freeman, Kathy Ierra, Bert Bates 著， O'Reilly台湾译，UMLChina改编�Q�中国电力出版社�Q?007�?br> 《掌握需求过�E?�W?�?�?/a>�Q�Suzanne Robertson/James Robertson 著，王�v�?译，人民邮电出版�C�，2007�?/font>
《��Y件工�E�实践者的研究�Ҏ��原书�W?版�?/a>�Q�Roger S. Pressman 著，郑�h�?马素�?白晓�?译，机械工业出版�C�，2006�?br> 《重构与模式�?/a>�Q�JOSHUA KEREVSKY 著，杨光/刘基�?译，人民邮电出版�C�，2006�?br> 《设计模式初学者指南�?/a>�Q�Allen Holub 著，徐迎�?译，机械工业出版�C�，2006�?br> 《程序开发原�?-抽象、规��g��面向对象设计�?/a>�Q�Barbara Liskov, John Guttag 著，裘健译，电子工业出版�C�，2006�?br> 《设计模式解析（�W?版）�?/a>�Q�Alan Shalloway, James R.Trott 著，徐言�?译，人民邮电出版�C�，2006�?br> 《Visual Basic设计模式�?/a>�Q�Mark Grand, Brad Merrill 著，杨环英、周锐博译，人民邮电出版�C�，2006�?br> 《UML用户指南�Q�第2版）�?/a>�Q�Grady Booch,James Rumbaugh,Ivar Jacobson 著，�늻��?��d��?马浩��?刘辉译，人民邮电出版�C�，2006�?br> 《UML2.0和统一�q�程�Q�原书第2版） �?/a>�Q�Jim Arlow,Ila Neustadt 著，方贵�?胡辉�?译，机械工业出版�C�，2006�?br> 《MDA与可执行UML�?/a>�Q�Chris Raistrick,Paul Francis,John Wright 著，机械工业出版�C�，2006�?br> 《对象设计�?/a>�Q�Rebecca Wirfs-Brock, Alan McKean 著，人民邮电出版�C�，2006�?br> 《面向对象分析与设计�Q�UML 2.0版）�?/a>�Q�Mike O'Docherty 著，俞志��?译，清华大学出版�C�，2006�?/font>
《程序设计的模式语言-�?�?/a>�Q�John M.Vlissides, James O.Coplien, Norman L.Kerth 著，�Ҏ��?周毅译，清华大学出版�C�，2006�?br> 《领域驱动设计�?/a>�Q�Eric Evans 著，陈大峰、张泽鑫译，清华大学出版�C�，2006�?br> 《UML面向对象建模与设计（�W?版）�?/strong>�Q�Michael Blaha, James Rumbaugh 著，人民邮电出版�C�，2006�?br> 《统一�q�程最佛_��늧�交和产品化阶�D�c�?/strong>�Q�Scott W.Ambler 著，机械工业出版�C�，2005�?br> 《敏��h��据�?/strong>�Q�Scott W.Ambler 著，机械工业出版�C�，2005�?br> 《过�E�模式（上册�Q��?/strong>�Q�Scott W.Ambler 著，人民邮电出版�C�，2005�?br> 《面向模式的软�g体系�l�构�Q�卷3�?/strong>�Q�Michael Kircher, Prashant Jain 著，机械工业出版�C�，2005�?br> 《Enterprise Java with UML 中文版�?/strong>�Q�C.T.Arrington、Syed H.Rayhan 著，机械工业出版�C�，2005�?br> 《��^衡敏捷与规范�?/strong>�Q�Barry Boehm、Richard Turner 著，清华大学出版�C�，2005�?br> 《UML参考手�?�Q�第2版）�?/strong>�Q�James Rumbaugh、Ivar Jacobson、Grady Booch 著，机械工业出版�C�，2005�?br> 《The Object Primer中文版�?/strong>�Q�Scott W.Ambler 著，机械工业出版�C�，2005�?br> 《C#设计模式�?/strong>�Q�Steve John Metsker 著，中国电力出版�C�，2005�?br> 《重构极限编�E�—XP的实践与反思�?/strong>�Q�Matt Stephens、Doug Rosenberg 著，清华大学出版�C�，2005�?br> 《Clouds to Code 中文版�?/strong>�Q�Jesse Liberty 著，徐峰译，电子工业出版�C�，2005�?br> 《对象模型：�{�略、模式与应用》（�W?版）�Q�Peter Coad 著，�U�学出版�C�，2005�?br> 《用例驱动UML对象建模应用——范例分析�?/strong>�Q�Doug Rosenberg、Kendall Scott 著，人民邮电出版�C�，2005�?br> 《DSDM业务中心框架开发方法（�W�二版）�?/strong>�Q�DSDM Consortium、Jennifer Stapleton 著，人民邮电出版�C�，2005�?br> 《UML�_��a——标准对象徏模语�a��明指南》（�W?版）�Q�Martin Fowler 著，徐家��?译，清华大学出版�C�，2005�?br> 《��Y件开发问题框�Ӟ��现实世界问题的结构化分析�?/strong>�Q�Michael Jackson 著，机械工业出版�C�，2005�?br> 《UML对象、组件和框架——Catalysis�Ҏ��?/strong>�Q�Desmond Francis D’Souza、Alan Cameron Wills 著，清华大学出版�C�，2004�?br> 《UML 2工具��?/strong>�Q�Hans-Erik Eriksson 著，电子工业出版�C�，2004�?br> 《��Y仉��求》（�W?版）�Q�Karl E.Wiegers 著，清华大学出版�C�，2004�?br> 《程序设计的模式语言-�?�?/strong>�Q�Neil Harrison、Brian Foote、Hans Rohnert 著，清华大学出版�C�，2004�?br> 《程序设计的模式语言-�?�?/strong>�Q�Robert Martin、Dirk Riehle、Frank Buschmann 著，清华大学出版�C�，2005�?br> 《超��传�l�的软�g开发——极限编�E�的�q�象与真实�?/strong>�Q�雷剑文陈振�?李明�?著，电子工业出版�C�，2005�?/font>
《Contributing to Eclipse中文�?/strong>》，Erich Gamma、Kent Beck 著，中国电力出版�C�，2005�?br> 《数据模型资源手册（�?�Q�》（修订版）�Q�Len Silverston 著，机械工业出版�C�，2004�?/font>
《OOD启思录�?/strong>�Q�Arthur J.Riel 著，人民邮电出版�C�，2004�?br> 《探索需求——设计前的质量�?/strong>�Q�Donald C. Gause, Gerald M. Weinberg 著，清华大学出版�C�，2004�?br> 《OMT应用�?/strong>�Q�Kurt W.Derr 著，清华大学出版�C�，2004�?br> 《企业应用架构模式�?/strong>�Q�Martin Fowler 著，机械工业出版�C�，2004�?br> 《数据徏模：分析与设计的工具和技术�?/strong>�Q�Steve Hoberman 著，机械工业出版�C�，2004�?br> 《UML基础、案例和应用》（�W?版）�Q�Joseph Schmuller 著，李虎译，人民邮电出版�C�，2004�?br> 《用UML设计�q�发、分布式、实时应用�?/strong>�Q�Hassan Gomaa 著，北京航空航天大学出版�C�，2004�?br> 《面向模式分析和设计——通过模式合成来进行��Y件系�l�的设计》（影印版）�Q�Sherif Yacoub, Hany Ammar 著，中国电力出版�C�，2004�?br> 《UML风格�?/strong>�Q�Scott W. Ambler 著，王少�?译，清华大学出版�C�，2004�?br> 《��Y仉��求管理：用例�Ҏ��》（�W?版）�Q�Dean Leffingwell, Don Widrig 著，蒋慧译，中国电力出版�C�，2004�?/font>
《UML业务建模�?/strong>�Q�Hans-Erik Eriksson, Magnus Penker 著，夏昕、何克清译，机械工业出版�C�，2004�?br> 《解析MDA�?/strong>�Q�Anneke Kleppe,Jos Warmer,Wim Bast 著，鲍志�?译，人民邮电出版�C�，2004�?br> 《��生式�~�程——方法、工具与应用�?/strong>�Q�Krzysztof Czarnecki,Ulrich W.Eisenecker 著，梁�v�?译，中国电力出版�C�，2004�?br> 《C++�|�络�~�程 �?�Q�运用ACE和模式消除复杂性�?/strong>�Q�Douglas C.Schmidt,Stephen D.Huston 著，於春�?译，华中�U�技大学出版�C�，2003�?br> 《分析模式：可复用的对象模型�?/strong>�Q�Martin Fowler 著，樊东�q?张�\ 译，机械工业出版�C�，2004�?br> 《敏捯��Y件开发�?/strong>�Q�Alistair Cockburn 著，俞涓译，人民邮电出版�C�，2003�?br> 《实时UML——开发嵌入式�pȝ��高效对象�?/strong>�Q�Bruce Powel Douglass 著，��Ҏ��?译，中国电力出版�C�，2003�?br> 《用UML构徏Web应用》（�W?版）�Q�Jim Conallen 著，陈�v 译，中国电力出版�C�，2003�?br> 《应用MDA�?/strong>�Q�David S.Frankel 著，鲍志�?译，人民邮电出版�C�，2003�?/font>
《�h本界面：交互式系�l�设计�?/strong>�Q�Jef Raskin 著，史元�?译，机械工业出版�C�，2003�?br> 《面向模式的软�g体系�l�构 �?�Q�用于�ƈ发和�|�络化对象的模式�?/strong>�Q�Douglas Schmidt 著，张志��?译，机械工业出版�C�，2003�?br> 《面向对象分析与设计�Q�原书第2版）�?/strong>�Q�Grady Booch 著，冯博�?译，机械工业出版�C�，2003�?br> 《敏捯��Y件开发：原则、模式与实践�?/strong>�Q�Robert C. Martin 著，邓辉译，清华大学出版�C�，2003�?br> 《VS.NET UML建模高��~�程——应用Visio for Enterprise Architects�?/strong>�Q�Andrew Filev 著，冯丽译，清华大学出版�C�，2003�?br> 《面向对象��Y件设计经典�?/strong>�Q�Rebecca Wirfs-Brock 著，张金�?译，电子工业出版�C�，2003�?br> 《有效用例模式�?/strong>�Q�Steve Adolph, Paul Bramble 著，车立�U?译，清华大学出版�C�，2003。UMLChina训练教材�?br> 《用例徏模�?/strong>�Q�Kurt Bittner 著，姜昊译，清华大学出版�C�，2003�?br> 《面向对象方法原理与实践》（�W?版）�Q�Ian Graham 著，袁兆�?译，机械工业出版�C�，2003。对象技术知识大全�?br> 《统一软�g开发过�E�之路�?/strong>�Q�Ivar Jacobson 著，�E�宾朱鹏张嘉�?译，机械工业出版�C�，2003。其实是Ivar Jacobson�?0�q�代的文集�?/font>
《面向对象��Y件构造（�W?版）》（影印版）�Q�Bertrand Meyer�Q�机械工业出版社�Q?003�?/font>
《��Y件复用：�l�构、过�E�和�l�织�?/strong>�Q�Ivar Jacobson 著，韩柯译，机械工业出版�C�，2003�?/font>
《面向模式的软�g体系�l�构 �?�Q�模式系�l��?/strong>�Q�Frank Buschmann �{?著，贲可�?译，机械工业出版�C�，2003�?br> 《编写有效用例�?/strong>�Q�Alistair Cockburn 著，王雷、张�?译，机械工业出版�C�，2002�?/font>
《面向对象的软�g��试�?/strong>�Q�John D.McGregor David A.sykes 著，杨文�?译，机械工业出版�C�，2002�?/font>
《UML with Rational Rose 2002 从入门到�_�N��?/strong>�Q�电子工业出版社�Q?002。用来学习工��h��作，书中�Ҏ��不可学�?
《统一软�g开发过�E��?/strong>�Q�Ivar Jacobson�Q�James Rumbaugh�Q�Grady Booch 著，周伯�?译，机械工业出版�C�，2002�q?月�?br> 《UML面向对象设计基础�?/strong>�Q�Meilir Page-Jones著，包晓露等译，人民邮电出版�C�，2001�q?月第1版�?
《Oracle 8 UML对象建模设计�?/strong>�Q�机械工业出版社�Q?000�q?月。很实用�?br> 《设计模�?可复用面向对象��Y件的基础�?/strong>�Q�Erich Gamma�{?著，李英�?译，机械工业出版�C�，2000
《面向对象的分析�?/strong>�Q?#8220;面向对象的设�?#8221;�Q�两本小册子�Q�Peter Coad�Q�Edward Yourdon著，�늻�忠等译，北大出版�C�，原书1991�q�写��。国内第一本关于面向对象分析和设计的书�?
《实用面向对象��Y件工�E�教�E��?/strong>�Q�Edward Yourdon, Carl Argila著，电子工业出版�C�，原书1995�q?2月写��?
《面向对象的�pȝ��分析�?/strong>�Q�邵�l�忠�Q�杨芙清�Q�清华大学，�q�西�U�技出版�Q?998�q?2月第一版�?

以下是UMLChina 参与制作的一些书�c��?

软�g工程



2002�q�《�h月神话》创下销售记�?br>2003�q�《最后期限》、《�h件》、《�h月神话》分别排在china-pub�q�度总销售榜�?�?�?�?/p>

需�?/font>

设计



子弹 2008-07-21 14:56 发表评论

C++ Tips[ZT]

子弹 — Fri, 18 Jul 2008 01:17:00 GMT
C++ Tips

C++ Tips Sections Intro I. ABCs and Inheritance II. Scope III. CLASSES IV. MISC V. OVERLOADING VI. PARAMETERS VII. Constructors (more on classes) VIII.EXCEPTIONS IX. TEMPLATES (more on classes) Intro This is not a code guideline document. See the C++ Style Guide for guidelines. This is more of a document to fuel questions while you design and code with C++. In some cases the point is simply stated and probably comes off as a rule. In reality, they are simply meant as rules of thumb. One of the main problems in C++ (more so than C) is that C++ provides many mechanisms in the language by which the same task can be achieved through different policies. For example, C++ has the Polymorphism mechanism. Some of the policies are templates, macros, inheritance, overloading, (those are the static, compile-time ones), and virtual functions (the run-time polymorphic policy). Hopefully the following will provide enough fuel for questions to arrive at the best policy to use for a particular design. I. ABCs and Inheritance ----------------------- 1. Abstract Base Class (ABC) : Make ABC class constructor protected when possible. Derived classes can have public constructor to override this. The same is true for non-ABC classes as well. 2. Class Inheritance : Use protected keyword where ever possible, never use public to expose data members so the inheriting classes have access to them. 3. Multiple Inheritance and VBC's :The only drawback is the most derived class must initialize the lowest base classes. This breaks encapsulation. Most people view multiple inheritance as a bad thing, but when used sparingly for parts of a design, there is no problem with it. 4. Data in classes should be keep private as much as possible. Use a member function if a client needs to access the data. If a member function does not need to be seen by a client, make it private. If the class might be inherited, then protected may be a good choice. 5. Private inheritance: Don't use it. Too many ambiguities when used with run-time type identification. Use a private data member instead or use public inheritance. Example: class Foo: private Bar { ... } dont do 6. Inheritance & virtual overrides: Care must be taken in overriding inherited functions. Sometimes functions are grouped together, and all need to be overridden. The base class designer must make this clear, if overriding one function requires multiple functions to be overridden. 7. Inheritance & Get/Set functions: Typically functions that perform Get/Set shouldn't be overridden unless they are used by the derived class. Otherwise if the base class does direct field manipulation, you usually can't override it correctly, or it could be a maintenance nightmare. Note: Get/Set functions as referred to above are merely meant as abstractions. As a rule of thumb (thumb must be getting pretty big by now), one should not create functions called Get or Set, or flavors thereof. They tend to break the spirit of encapsulation. Of course, there will be times to use them. II. SCOPE --------- 1. Law of Demeter : Do not make references to classes in a class that are not variables of the class, inherited by the class, or global. This also applies to including header files. Example: class Foo{public: Go(){} }; class Bar{ Foo aFoo; public: Foo GetFoo(){return aFoo;} }; class Fubar{ public: void Bad(){ Bar aBar; aBar.GetFoo().Go(); } }; The method Bad() breaks encapsulation. It calls a method of a class it probably does not need to know about. This will also affect maintainability. If the Foo class changes, the changes may also need to be done in the Fubar class. The other side of the coin that must be looked at is do you want a pass-through method in the Bar class that simply calls the Go() method of the Foo class. Lots of silly simple 1 line member functions may not be desirable in all the classes. What probably needs to be looked at to decide what road to take is speed, or perhaps redesign the classes. Beyond the Law of Demeter is Doug's rule of thumb: Don't play hide and seek with data. 2. Scope: Another way to say the previous point is to keep scope small. This will increase the lifetime of the code and keep it maintainable and safe. III. CLASSES ------------ 1. Be explicit about the keywords, public, protected, and private in a class interface. Try not to have multiple sections. In other words, multiple private sections in the class interface. It is generally a good idea to place the public section first because this is what most people are looking for when they go to use a class. 2. Make classes as atomic as possible. Give them a clear purpose. Break them into smaller classes if they become too complex. This may also eliminate duplicate code. 3. Don't let the compiler generate the default constructor,destructor, operator= and copy constructor. If the class is entirely value based, this is probably fine, if not, for example, if the class has a data member that is a pointer, the above will probably not work. Note, the default copy constructor only does a memcpy of the class, so all you copy is the pointer data. This may not be sufficient for copying a class. Regardless, if you do want the default ones, place them in the code, and leave them commented. For example: // Fubar(const Fubar&) use default copy constructor 4. If your class contains pointers, you should create the default constructor destructor, operator=, and copy constructor. 5. Class Copy: If the class should never be copied, then place the copy constructor in the private section and don't implement it. The linker will catch this, and the program will fail to build. This, although not graceful, is better than a malformed program. 6. Initialization: Perform all data member initialization in the constructor. It's best not to leave uninitialized objects running around in the system. Note, it is often more efficient using the constructor initializer list, otherwise, the default constructor would be called, and then you probably call member functions of the object later in the constructor. For example: class Foo{ Bar mung; Foo(int iCount) : mung(iCount) {} ... }; The variable mung is initialized once. But in the following: class Foo{ Bar mung; Foo(int iCount){ mung = iCount; } ... }; mung's default constructor is called before the body of the class Foo's constructor is entered. Then mung is set again - this assumes that mung has an assignment operator. The net effect is that mung is initialized twice. 7. Class Naming: There exists several ways to name classes that seem to work well for certain groups or people. There is Hungarian notation and the "Taligent's Guide to Designing Programs" that document some of the more typical methods. IV. MISC -------- 1. Implicit int: The 'implicit int' rule will go away in the next C++ standard. So for a proto like: 'main()' you will have to say 'int main()' in the future. Same for variables. 2. Preprocessor: Avoid it. Use const values in the class, or inline functions instead of macros. This is not to say, never use any #defines. Main reason: #define MIN(a,b) ( (aSomeFunction(); } V. OVERLOADING -------------- 1. operator overloading: It's syntactic sugar. Don't add them if they are not needed. This does NOT refer to the typical ones like '=', '==', but ones like '()', '[]', '+'. It does not always make sense to add two objects together. 2. Overloading: If a member function is conditionally executing code, it may be a candidate for operator overloading, or just overloading. 3. Operator overloading and chaining: When designing an overloaded operator, think about whether it needs to be chained. For example: String cstr = "a" + "b" + "c"; The String class's operator returns a reference to the String class. A partial implementation might be: class String{ public: String& operator+(const char *pcBuf){ // code to add the char* to the string return *this; } ... }; VI. PARAMETERS -------------- 1. Argument Passing: The first choice is typically a const ref. The const ref is basically an alias, and is easier to use than a pointer. It creates the same amount of instruction code as passing a pointer (for most cases). It's typically better than passing by value, where an object constructor will be called (if its an object). As a rule of thumb, you might want too give the following a whirl: IN const & OUT & If the object has the support functs INOUT *& Acts like a **. So for an IN parameter, what the 'const &' says, is here is a reference to it, but you cannot modify the object. But you can call member functions that do not change the object ( member functions defined as const). The OUT parameter is a parameter that is passed to a function that will modify it. If the parameter needs to be created, then the INOUT parameter of *& may be a good choice. 2. Returning Ref: In functions that return a reference, remember not to reference a temporary object and return it. For example: String &Zippo(void){ .... return String(); What happens, is that the String() is a temporary object that upon return goes out of scope and is destroyed. Thus, you return a reference to a destroyed object. Unfortunately, the program will probably work in most cases till it's shipped. The ol' Heisenbug! 3. Ref vs Pointer: Here's another way to look at when to use references, and when should to use pointers. C programmers sometimes don't like references since the reference semantics they provide isn't *explicit* in the caller's code. After a bit of C++ experience, however, one quickly realizes this "information hiding" is an asset rather than a liability. In particular, reuse-centered OOP tends to migrate the level of abstraction away from the language of the machine toward the language of the problem. References are usually preferred over ptrs whenever you don't need "re-seating". This usually means that references are most useful in a class' public interface. References then typically appear on the skin of an object, and pointers on the inside. The exception to the above is where a function's parameter or return value needs a "sentinel" reference. This is usually best done by returning/taking a pointer, and giving the nil ptr (0) this special significance (references should always alias *objects*, not a dereferenced nil ptr). VII. Constructors (more on classes) ----------------------------------- 1. Creating Constructors: These creatures should be simple. Try not to do anything in them that may generate errors. Remember they don't have return values. If it's necessary to allocate memory or other complex things in the constructor, throw an exception if possible as the first recourse. Else, the class will have to be protected everywhere that may use something that may be in error. It's generally not a pretty sight to see an error returned in the constructor's signature. 2. Constructors: Another reason to keep them simple is in the case of inheritance. 3. Destructors: It's responsibility is to release resources allocated during the class's lifetime, not just from construction. 4. Member Initialization List: The constructor can have a comma separated member initialization list. If a class contains value based classes as data members, they can be initialized in the constructor. For example: class Foo{ String cstr1; // value based class called String String cstr2; // value based class called String public: Foo(const char* pcStr1, const char*pcStr2): cstr1(pcStr1), cstr2(pcStr2){} }; With the variables cstr1, and cstr2 initialized in the constructor, they are initialized only once. Else, if they were initialized in the body of the constructor, they would first be initialized with a default constructor, then again in the body. VIII. EXCEPTIONS ---------------- 1. Exceptions: Use exception hierarchies, possibly even derived from the Standard C++ ones. 2. Exceptions: Throw exceptions by value and catch them by reference. This way the exception handling mechanism cleans up anything created on the heap. If you throw exceptions by pointer, the catcher must know how to destroy them. This is probably not a good coupling. Even so, any up casting may slice and dice the object. IX. TEMPLATES (more on classes) ------------------------------- 1. Templates: Before creating new ones, see if they are in RogueWave, or part of the C++ Standard. 2. Templates: When creating them, try to filter out any code that does not depend on the type, and place that into a base class. Thus, the template class itself is only the necessary information that depends on type. Good examples can be found in RogueWave.

Douglas J. Waters
(best reached on the internet)
Internet: waters@openmarket.com
Phone: (781) 359-7220

��л��ǵ��վ��ܻ��Դ��Ȥ��
精品视频久久久久

��ҹ��Ӱ�þ�| �ݺ�ɫ��þ��| ��a��ѹۿ��þ�av | ��ŷ��պ��þ�AV��| �þþ�Ʒ��վ��| ��Ʒ��պ��þ��| ��ۺϾþþþ��ۺ��| 97�þþþ�Ʒ�ۺ�88�þ�| ��˾�Ʒ�ۺϾþþ�| ��˾þô��߽��ۺ��վ| 99��Ʒ��ۺϾþþþ��| 99�þ�99�þþ�Ʒ��ѿ�� | ��޺ݺݾþ��ۺ�һ��77777| �þþ�Ʒ��7777| �ݺ�ɫ�ۺ��վ�þþþþþø��| �þþþ�Ʒ��sm��վ| �þþþ��ֻ�о�Ʒ | �þù��¶��Ʒ��Ӱ| 99�þó��Ļ��| ��޹��˾�Ʒ91�þþ�| �þþ��Ƶ��| �þù��ֱ��| �þþþ��޾�Ʒ��Ļ| �þþþ�99��Ʒ��Ƭֱ��| ��Ļ��˾þ��| 91��Ʒ��ۺϾþþ�Ʒ| �þ�ҹɫ��Ʒ��a | �þþþ��AV��Ƭ | ��ɫ��þþþþþ�С˵ | �þþþ��AV��| ��ҹ��Ʒ�þþþþ�| ��޹��Ʒ�þþþ�� | 91��޹��˾þþ�Ʒ| һ��ɫ��þ�99һ�ۺ�| �þ��ۺϺݺ��ۺϾþ�97ɫ| 99�þó��18��վ| 99�þ�99�þþþ�Ʒ��| �þ��Av��Դ��վ�� | �þþ�Ʒ��Դվ| 77777��ҹ�þö��| ��AV��˾þ��ԭ|

子弹 2008-07-18 09:17 发表评论

子弹 — Wed, 16 Jul 2008 09:12:00 GMT

[轉]C++�E�序设计最佛_��?/div>
2007�q?4�?3�?星期一 00:57

　　随着计算��a�的发展，我们现在�~�写一个程序越来越�Ҏ��了。利用一些��Y件开发工��P��往往只要通过鼠标的拖拖点点，计算机就会自动帮你生成许多代码。但在很多时候，计算机的�q�种能力被滥用了�Q�我们往往只考虑把这个程序搭��h��Q�而不去考虑�E�序的性能如何�Q�程序是否��够的健壮。而此节课的目的主要是介绍一些编码的�l�验�Q�让大家�~�写的程序更加健壮和高性能�?br>
　　1、Prefer const and inline to #define

　　在C++�~�程中应该尽量��用const和inline来代�?define�Q�尽量做到能不用#define��׃��用�?define常见的用途有“定义帔R��”以及“定义�?#8221;�Q�但其中存在诸多的弊病�?

　　�W�一�Q�查错不直观�Q�不利于调试。Define的定义是由预处理�E�序处理的，作的是完全的文本替换�Q�不做�Q何的�c�d��查。在�~�译器处理阶�D�，define定义的东西已�l�被完全替换了，�q�样在debug的时候就看不��C�Q何的相关信息�Q�即跟踪时不能step into宏。例如，把ASPECT_RATIO用define定义�?.653�Q�编译器��q��不到ASPECT_RATIO�q�个名字了。如果编译器�?.653错，那么��无从知道此1.653来自于何处。在真正�~�码的时候应该��用如下的语句来定义：

static const double ASPECT_RATIO = 1.653;

　　�W�二�Q�没有�Q何类型信息，不是type safe。因为它是文本��别的替换�Q�这样不利于�E�序的维护�?br>
　　�W�三�Q�define的��用很�Ҏ��造成污染。比如，如果有两个头文�g都定义了ASPECT_RATIO, 而一个CPP文�g又同时包含了�q�两个头文�g�Q�那么就会造成冲突。更难查的是另外一�U�错误，比如有如下的代码�Q?br>　　// in header file def.h
　　#define Apple 1
　　#define Orange 2
　　　 #define Pineapple 3
　　 …
　　// in some cpp file that includes the def.h
　　enum Colors {White, Black, Purple, Orange};

　　�?h文�g中Orange被定义成水果的一�U�，而在.cpp文�g中Orange又成��Z��一�U�颜�Ԍ��那么�~�译器就会把此处的Orange替换�?�Q�编译可能仍然可以通过�Q�程序也能够�q�行�Q�但是这��成了一个bug�Q�表现出古怪的错误�Q�且很难查错。再比如定义了一个求a与b哪个数大的宏�Q?define max(a,b) ((a) > (b) ? (a) : (b))
　　int a = 5, b = 0;
　　max(++ a, b);
　　max(++ a, b + 10);

　　在上面的操作中，max(++ a, b); 语句中a�?+了两�ơ，而max(++ a, b + 10); 语句中a只加了一�ơ，�q�样在程序处理中��很有可能成��Z��个bug�Q�且此bug也非常的难找。在实际�~�码时可以��用如下的语句来做�Q?br>　　template
　　inline const T&
　　max(const T& a, const T& b) { return a > b ? a : b; }

　　2、Prefer C++-style casts

　　在程序中�l�常会需要把一�U�类型�{换成另外一�U�类型，在C++中应该��用static_cast、const_cast、dynamic_cast、reinterpret_cast关键字来做类型�{换。因��有以下好处，一是其本��n��是一�U�注释，在代码中看到上面�q�些关键字就可马上知道此处是�q�行�c�d��转换。二是C语言中类型�{换通常是很难进行搜索的�Q�而通过关键字cast则可以很�Ҏ��的找到程序中出现�c�d��转换的地方了�?br>
　　3、Distinguish between prefix and postfix forms of increment and decrement operators

　　通常对于操作�pȝ��或编译器自��n支持的类型，prefix�Q�前�~��Q�如++i�Q�与postfix�Q�后�~��Q�如i++�Q�的效果是一��L��。因为现在的�~�译器都很聪明，它会自动做优化，�q�两者的汇编代码是一��L��Q�性能不会有差别。但有时候也会有不同的，如一些重载了操作�W�的�c�d��。下面是模拟prefix与postfix的操作过�E�，可以发现在postfix操作中会生成一个��时变量，而这一临时变量是会占用额外的时间和开销的�?br>　　// prefix form: increment and fetch
　　UPInt& UPInt::operator++()
　　　{
　　　 *this += 1; // increment
　　　return *this; // fetch
　　　}
　　// postfix form: fetch and increment
　　　const UPInt UPInt::operator++(int)
　　　{
　　　 UPInt oldValue = *this; // fetch
　　　++(*this); // increment
　　　 return oldValue; // return what was fetched
　　 }

　　一般情况下不需要区分是�?+�Q�还是后++�Q�但是我们在�~�写�E�序的时候最好能习惯性的��其写成++i的�Ş式，如在使用STL中的iterator�Ӟ��prefix与postfix会有相当大的性能差异。请不要��看�q�些�l�节�Q�实际在�~�写�E�序的时候，若不注意具体�l�节�Q�你会发现程序的性能会非常的低。但要注意，虽然在大多数情况下可以用prefix来代替postfix�Q�但有一�U�情况例外，那就是有[]操作�W�时�Q�比如gzArray [++index] 是不�{�于 gzArray[index++]的�?/font>

4、Minimizing Compile-time Dependencies

　　有些人在�~�写�E�序�Ӟ��往往喜欢��一�?h文�g包含到另一�?h文�g�Q�而实践证明在做大型��Y件时�q�是一个非�怸�好的习惯�Q�因�q�样会造成很多依赖的问题，包含较多�?h文�g�Q�别人又使用了这个class�Q�而在他的那个工程中可能�ƈ不存在这�?h文�g�Q�这样很可能��q��译不能通过。而且�q�样做，�q�可能造成很难��L��C��个模块的情况。因��Z��?h文�g被很多模块包含的话，如果修改了此.h文�g�Q�在�~�译�pȝ��的时候，�~�译器会��d��扑֓�些模块依赖于某个被修改过�?h文�g�Q�那么就��D��了所有包含入�?h文�g的模块全都要�q�行重新�~�译。在��目比较��的时候，大家可能�q�感觉不到差别，但是如果说是在大型的软�g�pȝ��里，你可能编译一遍源码需要七、八个小时。如果你�q�个.h文�g被很多模块包含的话，��q��?h文�g中加了一行注释，在编译时�~�译器检查哪些文件被改动�Q�那么所有包含入�?h文�g的模块都会被重新�~�译�Q�造成巨大的时间和�_�֊�负担。对于此问题�Q�解决的�Ҏ��是�?h文�g自包含，也就是说让它包含��量��的东西。所谓尽量少是指如删掉�Q何一个它包含�q�来�?h文�g�Q�都��无法正常进行工作。其实在很多情况下，�q�不需要一�?h文�g��d��含另一�?h文�g�Q�完全可以通过class声明来解决依赖关�pȝ��q�种问题。再来看下面�q�个例子�Q?br>　　#include "a.h" // class A
　　#include "b.h" // class B
　　#include "c.h" // class C
　　#include "d.h" // class D
　　#include "e.h" // class E
　　class X : public A, private B
　　{
　　　public:
　　E SomeFunctionCall(E someParameter);
　　　private:
　　 D m_dInstance;
　　};

　　当类X从类A和类B中派生时�Q�需要知道X在内存中都有哪些data�Q�通常在内存中前面是基�cȝ��data�Q�后面紧跟的是此�z��c�自�w�定义的data�Q�因此就必须知道�c�A与类B的内部细节，要不然编译器��无法来安排内存了。但是在处理参数以及参数�q�回值的时候，实际上�ƈ不需要知道这些信息，在此处定义的SomeFunctionCall()只需知道E是个class��p��够了�Q��ƈ不需要知道类E中的data如长度等的具体细节。上面的代码应该改写成如下的形式�Q�以减少依赖关系�Q?br>　　#include "a.h" // class A
　　#include "b.h" // class B
　　#include "c.h" // class C
　　#include "d.h" // class D
　　class E;
　　class X : public A, private B
　　{
　　　public:
　　E SomeFunctionCall(E someParameter);
　　　private:
　　D m_dInstance;
　　};

　　5、Never treat arrays polymorphically

　　不要把数�l�和多态一起��用，��L��下面的例子�?br>　　class BST { ... };
　　class BalancedBST: public BST { ... };
　　void printBSTArray(ostream& s, const BST array[], int numElements)
　　{
　　for (int i = 0; i < numElements; ++i)
　　{
　　 s << array[i];
　　// this assumes an operator<< is defined for BST
　　}
　　}

　　BalancedBST bBSTArray[10];
　　printBSTArray(cout, bBSTArray, 10);

　　数组在内存中是一个连�l�的内存�I�间�Q�而在数组中应该如何来定位一个元素呢�Q�过�E�是�q�样的，�~�译器可以知道每个数据类型的长度大小�Q�如果数�l�的index�?�Q�则会自动去取第一个元素；如果是指定了某个index�Q�编译器则会�Ҏ��此index与该数据�c�d��的长度自动去��出该元素的位置�?br>
　　在printBSTArray()函数中，��管传入的参数是BalancedBST�c�d��Q�但�׃��其本来定义的�c�d��是BST�Q�那么它依然会根据BST来计��类型的长度。而通常�z��c�d��例所占的内存要比基类实例所占的内存大一些，因此该程序在�~�译时会报错。请��C��Q�永�q�不要把数组和C++的多态性放在一起��用�?br>
　　6、Prevent exceptions from leaving destructors

　　析构函数中一定不要抛出异常。通常有两�U�情况会��D��析构函数的调用，一�U�是当该�cȝ��对象��d��了它的域�Q�或delete表达式中一个该�c�d��象的指针�Q�另一�U�是�׃��异常而引��h��构函数的调用�?br>
　　如果析构函数被调用是�׃��exception引�v�Q�而此时在析构函数中又抛出了异常，�E�序会立卌��pȝ��l�止�Q�甚至都来不及进行内存释放。因此如果在析构函数中抛出异常的话，��很�Ҏ��h��引�v异常的原因，且这��L��软�g也会让用户非常恼火。由于析构函��C��很可能会调用其它的一些函敎ͼ�所以在写析构函数的时候一定要注意�Q�对�q�些函数是否会抛出异常要非常清楚�Q�如果会的话�Q�就一定要��心了。比如下面这�D�代码：
　　Session::~Session()
　 {
　　logDestruction(this);
　 }

　　比如logDestruction()函数可能会抛出异常，那么我们��应该采用下面这�U�代码的形式�Q?
　　Session::~Session()
　 {
　　 try
　　{
　　　logDestruction(this);
　　 }
　　 catch (...)
　　{
　　 }
　}

　　�q�样�E�序出错的时候不会被立即��x��Q�可以给用户一些其它的选择�Q�至��先让他把目前在做的工作保存下来�?br>
　　7、Optimization:Remember the 80-20 rule

　　在��Y件界有一�?0-80法则�Q�其实这是一个很有趣的现象，比如一个程序中20%的代码��用了该程序所占资源的80%�Q�一个程序中20%的代码占用了总运行时间的80%�Q�一个程序中20%的代码��用了该程序所占内存的80%�Q�在20%的代码上面需要花�?0%的维护力量，�{�等。这个规律还可以被��l�推�q�下去，不过�q�个规律无法被证明，它是��Z��在实践中观察得出的结果。从�q�个规律出发�Q�我们在做程序优化的时候，��有了针�Ҏ��。比如想提高代码的运行速度�Q�根据这个规律可以知道其�?0%的代码占用了80%的运行时��_��因此我们只要扑ֈ��q?0%的代码，�q�进行相应的优化�Q�那么我们程序的�q�行速度��可以有较大的提高。再如有一个函敎ͼ�占用了程�?0%的运行时��_��如果把这个函数的执行速度提高10倍，那么对程序整体性能的提高，影响是非常巨大的。如果有一个函数运行时间只占��L��间的1%�Q�那��q��把这个函数的�q�行速度提高1000倍，对程序整体性能的提高也是媄响不大的。所以我们的基本思想��是扑ֈ�占用�q�行旉��最大的那个函数�Q�然后去优化它，哪怕只是改�q�了一点点�Q�程序的整体性能也可以被提高很多�?br>
　　要想扑և��?0%的代码，我们的方法就是��用Profiler�Q�它实际上是一些公司所开发的工具�Q�可以检查程序中各个模块所分配内存的��用情况，以及每个函数所�q�行的时间等。常见的Profiler有Intel公司开发的VTune�Q�微软公司开发的Visual Studio profiler�Q�DevPartner from Compuware�{��?

子弹 2008-07-16 17:12 发表评论

德鲁克的著作列表

子弹 — Mon, 14 Jul 2008 04:44:00 GMT
德鲁克的著作列表�Q�中文译名会因各出版�C�不同而不同，请以英文名称为准�Q�：
1. 《经��h的末日》（The End of Economic Man �Q? 1939
2. 《工业�h的未来》（The Future of Industrial Man�Q?- 1942
3. 《公司的概念》（Concept of the Corporation�Q?- 1946
4. 《新�C�会》（The New Society�Q?- 1950
5. 《个人推荐首扚w��诅R��《管理实��c��（The Practice of Management�Q?- 1954
6. 《美国的下一�?0�q�》（America's Next Twenty Years�Q?- 1957
7. 《明日的里程��》（Landmarks of Tomorrow�Q?- 1957
8. 《成果管理》（Managing for Results �Q? 1964
9. 《个人推荐首扚w��诅R��《卓有成效的��理者》（The Effective Executive�Q?- 1966
10. 《断层时代》（The Age of Discontinuity�Q?- 1968
11. 《技术、管理与�C�会》（Technology�Q?Management and Society�Q?- 1970
12. 《�h、思想与社会》（Men�Q?Ideas and Politics�Q?- 1971
13. 《个人推荐首扚w��诅R��《管理：��d��、责仅R��实��c��（Management: Tasks�Q?Responsibilities�Q?Practices�Q?- 1973
14. 《看不见的革命》（The Unseen Revolution�Q?- 1976 (1996�q�以《退休基金革命》（The Pension Fund Revolution�Q�重�?
15. 《�h与�W效：德鲁克论��理�_�֍�》（People and Performance: The Best of Peter Drucker on Management �Q? 1977
16. 《管理导论》（An Introductory View of Management�Q?- 1977
17. 《旁观者》（Adventures of a Bystander�Q?- 1978
18. 《毛�W�之歌：日本�l�画》（Song of the Brush: Japanese Painting from the Sanso Collection�Q?- 1979
19. 《动荡时代中的管理》（Managing in Turbulent Times�Q?- 1980
20. 《迈向经��新�U�元及其他论文》（Toward the Next Economics and Other Essays�Q?- 1981
21. 《变动中的管理界》（The Changing World of the Executive�Q?- 1982
22. 《最后可能出现的世界》（��说�Q�The Last of All Possible Worlds�Q?- 1982
23. 《行善的诱惑》（��说�Q�The Temptation to Do Good �Q? 1984
24. 《创��C��企业家精��》（Innovation and Entrepreneurship�Q?- 1985
25. 《管理的前沿》（Frontiers of Management: Where Tomorrow's Decisions are Being Shaped Today�Q?- 1986
26. 《新现实�Q�政府与政治、经��与企业、社会与世界》（The New Realities: in Government and Politics�Q?in Economics and Business�Q?in Society and World View�Q?- 1989
27. 《非营利�l�织的管理：原理与实��c��（Managing the Nonprofit Organization: Principles and Practices�Q?- 1990
28. 《�ؓ了未来－20世纪90�q�代及其以后的年代－而管理�?“Mananing for the Future:The 1990's and Beyond” - 1992
29. 《生态远景》（The Ecological Vision�Q?- 1993
30. 《后资本��M��C�会》（Post-Capitalist Society�Q?- 1993
31. 《巨变时代的��理》（Managing in a Time of Great Change�Q?- 1995
32. 《�d鲁克看亚�zԌ��德鲁克与中内的对话》（Drucker on Asia: A Dialogue between Peter Drucker and Isao Nakauchi�Q?-1997
33. 《�d鲁克论管理》（Peter Drucker on the Profession of Management�Q?- 1998
34. �?1世纪的管理挑战》（Management Challenges for the 21st Century �Q? 1999
35. 《�d鲁克�_�֍�》（The Essential Drucker�Q?- 2001
36. 《下一个社会的��理》（Managing in the Next Society�Q?- 2002
37. 《功能社会》（A Functioning Society �Q? 2002
38. 《个人推荐首扚w��诅R��《�d鲁克日志》（The Daily Drucker�Q?- 2004
39. 《卓有成效管理者的实践�?�Q�The Effective Executive in Action�Q?2006

子弹 2008-07-14 12:44 发表评论

Software quality

子弹 — Tue, 17 Jun 2008 07:06:00 GMT
     摘要: Software quality From Wikipedia, the free encyclopedia Jump to: navigation, search This article may require cleanup to ...  阅读全文

子弹 2008-06-17 15:06 发表评论

子弹 — Tue, 17 Jun 2008 06:08:00 GMT

建立你自��q��温伯格图书馆

    9月，清华大学出版�C�N��重推��Z��《��Y件与�pȝ��思想家温伯格�_��a译丛》首批共6�U�。该丛书�?4�U�，均出自美国计��机界的泰斗人物杰拉��d·温伯��|��Gerald M. Weinberg�Q��?

    温伯格首要的贡献集中于��Y仉��域，他是从个体心理、组�l�行为和企业文化角度研究软�g��理和��Y件工�E�的权威和代表�h物。在��过40�q�的软�g职业生��中，温伯��g��事过软�g开发，软�g��目��理、��Y件管理教学和咨询�Q�他更是一位杰出的软�g专业作者和思想家�?997�q�_��温伯格因其在软�g领域的杰��A献，被美国计��机博物馆的计算机名人堂选�ؓ首批5位成员之一。这个名人堂至今只有20名成员。�ؓ中国读者所熟悉的比��?#183;盖茨和迈克尔·戴尔也是在温伯格之后�Ҏ��获得�q�一计算机界至高无上的殊荣�?

    温伯格精力旺盛、思想�z�跃�Q�从20世纪70�q�代开始，他��d��撰写�?0多本书籍和数以百计的论文。这些著作主要集中在两个主题�Q��h与技术的�l�合�Q��h的思维模式、思维习惯以及解决问题的方法。温伯格的大部分作品已经被翻译成10多种语言发行到法国、�d国、西班牙、葡萄牙、荷兰、俄�|�斯、日本等多个国家�Q?0余年畅销不衰。在西方国家乃至全世界，温伯格拥有大量忠实的读者群�Q�这�?�q�星�?阅读了温伯格的每本重要著作，他们甚至��有专门的�l�织和网站，讨论和交��大师的重要思想。可以说�Q�温伯格�q�年来的每本��C��都是在万众瞩目中推出的�?

    成熟的��Y件��业是��理实践和信息技术结合的产业。而��Y件管理思想的引�q�，比技术和资金更�ؓ紧迫和重要。在西方国家图书市场上，软�g��理图书非常多。浪里淘沙之中，温伯格的著作正是西方软�g��理思想发展和集大成的中��砥柱�?

            --��国计算机名人堂代表人物温伯格的思想�_�֍�
            --微��Y亚洲研究院院长兼首席�U�学家张亚勤强力推荐
            --12�U�语�a�的版本发行全世界�Q?0余年畅销不衰
            --提倡�h与技术相�l�合、引导系�l�化思维模式

�E�序开发心理学�Q�银�q�纪�늉��Q?/td>

√ "�q�是有史以来计算机编�E�领域的最�l�典的一部著作�?--Datamation
√ "一本杰作的新生�Q?#8230;…1971�q�_��当《程序开发心理学》首�ơ面世时�Q�我们都如雷轰�?-从未有�h提出软�g开发可以被看作是一�U��h�cȝ��z�d��。经历多�q�_��该书成�ؓ全球畅销�?#8230;…不管你是属于上世�U?0�q�代�?0�q�代那一代，�q�是属于80�q�代�?0�q�代的新一代，你要感谢你自己去拿�v�q�样一本奇妙的书。一旦你��M��它，你应该接着�q�读Weinberg所有其他的书，每一本都是一颗宝矟�?--Ed Yourdon, Cutter IT Journal
√ "《程序开发心理学�?#8230;…是第一本强调计��机�~�程是个人和团队共同努力�q�程的图书，�q�且成�ؓ了这个领域的�l�典图书……��管本书写作旉��用的�?971�q�的视角�Q�但�?0多年后的今天�Q�这本书�q�是所有��Y件开发经理们的必�ȝ��典�?--J.J.Hirschfelder�Q�Computing Reviews
√ "Gerald M. Weinberg是我的良师益友，我的同行�Q�也是我们这个职业（软�g开发）造就的最好的思想家和作�?#8230;…《程序开发心理学》一书写成于1969�q�_��1971�q�出版，自此被不断重华ͼ�光��印记录是��M��其他计算图书都未能比及的。大多数书中�?关于人的内容'比其中的技术更�l�得住时间的考验�?--Sue Petersen在Visual Developer Magazine�Q�March/April, 1999�Q�的评论
√ "Gerald M. Weinberg的《程序开发心理学�?是我最喜爱的一本关于��Y件开发的书�?#8230;…书中的有�?无私软�g开�?的观�?#8230;…带动了开放源码思想崛�v。好的��Y件工�E�思想要比具体的技术更�l�久不衰。就�q�一点而言�Q�没有一本书提供的思想可以与《程序开发心理学》中的思想相比�?--Steve McConnel�Q�IEEE�ȝ��Q�IEEE Software (Jan/Feb, 1999)
√ "Gerald M. Weinberg的经�怹�作《程序开发心理学》媄响了我的一�?#8230;…因�ؓ他认识到了一个随着旉��推移��变得越来越重要的问题：��x��和培育程序员和程序员队伍�?#8230;…和Fredrick Brooks的《�h月神话》一��P��Weinberg的《程序开发心理学》同��h��一本经久不衰的�l�典之作�?--Michael Schrage�Q�MIT Media Lab�Q?No More Teams!"一书的作者，摘自Computerworld
√ "《程序开发心理学》（银年�U�念版）�?971�q�该书第一�ơ出版后的修订本。这本书如何�q�能适合今天��Z��的口呛_��Q�答案很��单：人�ƈ没有真正改变�?#8230;…Weinberg在全书提供了无数强有力的�l�历旉��考验的见识，�q�些见识�q�去是正��的�Q�现在也仍然正确的�?#8230;…如果你在�q�本书中看不��C��些你自己�Q�你��׃��是一名计��机专业人员。买一本，读读它，然后把它留在你的�l�理的椅子上。相信你们俩都将受益匪浅�?--B. Scott Andersen�Q�Silver anniversary edition hits gold, Amazon.com (Feb 27, 2001)
√ "Weinberg在银�q�纪�늉�的每一章结��֤�都做了评注，�q�恪守了他在前言里的承诺�Q?我决不会��L��盖自��q��错误--因�ؓ也许正是通过�q�些错误�Q�我的读者才会获得更大的收获�?……有时侯，老书是最好的�Q�尤其是在对其做了修订、对当初的大胆预�a�和贤明徏议做了评仗��?--Johanna Rothman

�Q�The Psychology of Computer Programming : Silver Anniversary Edition�Q?/strong>

9月出版，敬请��x��Q?nbsp;        ISBN: 7-302-07026-1

    在计��机界，�q�没有�Q何一本计��机斚w��的书�Q�在初次出版之后�Q�能够在长达25�q�的岁月中一直保持活力——而且�q�种�z�d��C��天仍在��l�。《程序开发心理学》是开�?#8220;以�h为本”研究�Ҏ��的先驱，它以其对�E�序员们在智力、技巧、团队和问题求解能力�{�方面独特的视角和敏锐的观察�l�受住了旉��的考验�?

成�ؓ技术领��D��——解决问题的有机�Ҏ��

√ "�?4章的内容�Q�逻辑清晰、引发思考，帮助你如何完成从技术�h员到问题解决型领��D��的转变……一本实用的、实实在在的指南……热情、友好、诙谐的语言�Q�不时地�I�插着一些奇闻轶事，非常适合阅读�?--Cause/Effect
√ "本书可是看作是一本有兛_��展个人领��D��力的指南�Q�但是，本书的�h��g��只这�?#8230;…本书包含很多有关个�h职业成长非常实用和颇有�h值的观点……是这位作者写的最好的一本书之一�?--Journal of Systems Management
√ "《成为技术领��D��》可以指导所有领��D��ƈ使几乎�Q何一个领域的领导者受到鼓舞�?--Data Processing Digest
√ "温伯格在书中阐述了不同类型的领导行�ؓ�Q�分析了那些��L��我们�q�行有效领导或排斥他人领导的不利因素�Q��ƈ提出了能让我们把事情做得更好的行为。所有这些内定w��是通过他幽默和坦率的语�a�表达出来�?#8230;…��L��那么引�h入胜……�Ȁ发我们去思考如何��技术�h员在工作中进行有效的合作……温伯��g��仅在引导大家如何成�ؓ一名领��D��，他自己本�w�就是一名出色的领导者�?--IEEE Computer
√ "无论你是在管理单机、网�l�、还是多用户�pȝ��Q�你都将会发现这是一本条理清晰和内容�_��的好书�?--Computer Book Review

�Q�Becoming a Technical Leader: An Organic Problem-Solving Approach�Q?/strong>

9月出版，敬请��x��Q?nbsp;        ISBN: 7-302-06889-5

    本书阐述了作��Z��名成功领��D��所必须掌握的领导方法与技巧——创新、激励和�l�织。本书提��Z��一些方法，供读者分析自己在�q�三个方面的领导技巧，�q�提供了开发这些技巧所需的实跉|��骤。本书探讨的范畴不仅仅局限于技术层面，而且�q�拓展到了如何与他�h更好地协作。作者在讲解基本原理的过�E�中所丄��途R��事、类比与比喻令�h印象深刻�Q�因此有助于读者领会其中精要�?

�pȝ��化思维��D��Q�银�q�纪�늉��Q?/td>

√ 有关《系�l�化思维��D��》（银年�U�念版）的赞�?
√ 整理�?..

�Q�An Introduction to General System Thinking�Q?/strong>

9月出版，敬请��x��Q?nbsp;        ISBN: ISBN: 7-302-06804-6

    25�q�以来，《系�l�化思维��D��》在介绍�pȝ��理论斚w��被一致认为是一本创新性的著作�Q�在计算��Z��及其他各个领域获得了普遍的应用。在世界各地�Q�在译֠�上和研讨班，本书开启心��c��磨砺思维的威力得��C��断地证明�?

�pȝ��设计的一般原�?/td>

√ 有关《系�l�设计的一般原理》的赞誉
√ 整理�?..

�Q�General Principles of Systems Design�Q?/strong>

10月出版，敬请��x��Q?/td>

    本书一位计��机专家与一位�h�c�d��家思想的碰撞结�Ӟ��针对那些无法通过传统�Ҏ��加以解决的系�l�问题，本书为我们介�l�了分析与理解这�c�问题的新观点与�Ҏ��。本书是一本一般性系�l�思想著作�Q�对各个学科领域�Q�具有很�q�泛的适应性，不仅仅是关于计算机系�l�，�q�包括各�U�系�l�——�h�c�R��自然、科技。它提供了许多关于诸如设计信息处理系�l�、培训程序、商业组�l�、停车场、或都市人日常工作的应用实例�?

走查、审查与技术复审手册——对�E�序、项目和产品�q�行评估

√ 有关《走查、审查与技术复审手册》的赞誉
√ 整理�?..

�Q�Handbook of Walkthroughs, Inspections, and Technical Reviews : Evaluating Programs, Projects, and Products�Q?/strong>

9月出版，敬请��x��Q?ISBN: 7-302-06987-5

    �q�本备受赞誉和推崇的佳作�Q�可以让你学会如何将技术复核的�Ҏ��应用于各�U��品与软�g的开发过�E�。本书详�l�地解释了开展走查（或者同�U�团体复审）、审查和技术复审的��程�Q�同时还为每一�U�接受复审的材料�Q�包括规根{��设计和代码复审�Q�配备了详实的检查表�?

你的灯亮着吗？——发现问题的真正所�?/td>

√ "一本有兛_��何解决问题的最好的一本书�?#8230;…我强烈推荐这本书�?--John S. Rhodes, WebWord.com
√ "��Weinberg和Gause之手�W�的又一本神奇的力作�?--Barry Kornfeld, Sound Bytes
√ "作者用通俗易懂的故事，提出了他寚w��题定义的深刻见解以及实用的解决问题的�Ҏ��Q�这些见解和�Ҏ��对管理者的作用之大无法估量。尽��这一话题是非�怸�肃的�Q�但是行文却�q�默风趣�Q�完全不是一本讨论技术的书�?--Jim Van Speybroeck, Data Processing Digest
√ "�q�是�q�今为止�q�一领域最有趣、最有帮助的一本书。作者在分析和处理问题的�Ҏ��斚w��提出了很多颇有帮助和价值的��?--Charles Ashbacher, Amazon.com
√ "我管理着一个程序员团队。我希望他们头脑反映敏捷�Q�能够知道通向�E�序开发的捷径�Q�把握住�E�序开发真正问题之所在，然后��利解决�q�些问题。这��是��Z��么我�l�公叔R��的每一名程序员��C��q�本书�?--Garry Bor, 来自新加坡的一名��Y件工�E�师
√ "如果说这是一册教�U�书�Q�那一定是我太偏爱了故事；如果说这是一束小品文�Q�那一定是我太沉迷于思考；如果说这是程序员解决问题的指南，那一定是我忽略了问题的普遍性；如果说这��改变你的生�z�，那一定是你洞察了其中的奥�U��?--Citizen
√ "本书包含很多��h��深刻哲理的警句，诸如'不管看上��d��何，��Z��很少知道他们惌��什么，直到你给了他们想要的东西�?�Q?鱼��L��最后一个看到水的�?但是本书�q�不是简单的警句的罗列，它真的是一本有关问题解决的有趣的和有用的书�?#8230;…我已�l�读了两遍，我还会很快再��M��遍�?--Tim Ottinger, Object Mentor Inc.

�Q�Are Your Lights On? : How to Figure Out What the Problem Really Is�Q?/strong>

9月出版，敬请��x��Q?ISBN: 7-302-06888-7

    �q�是一本关于问题解决的书，在美�?0�q�畅销不衰。主要探讨了�?#8220;问题出现”�?#8220;军_��采用什么方式解册��问题”之间我们需要考虑的方斚w��面，从而教会你一�U�分析问题的全新思�\�Q�让你轻��L��松解决问题！20则幽默的��C��寓言故事�Q?0副精��的全彩卡通插图，您将看到大师温伯格如何改变我们的思考方式！

探烦需�?/td>

�Q�Exploring Requirement�Q?/strong>

2004�q?月出版。UMLChina隆重推荐�Q?/td>

    本书着��g��pȝ��设计之前的需求分析。通过对一些需求分析中的常见误区和问题的分析和讨论�Q�从和客��h��通开始，深入研究一些可能的需求，澄清用户和开发者期望��|��最�l�给��Z��能够大幅度提高项目成功几率的一些徏议方法。全书语�a�通畅�Q�词汇量��，通俗易懂�Q�层�ơ分明，是需求分析�h员的入门和提高指南�?

理解专业�E�序�?/td>

�Q�Understanding the Professional Programmer�Q?/strong>

2004�q�年初出版，敬请��x��Q?/td>

    本书是一本关于�h和思想斚w��的书。主要介�l�了对于�E�序员这个职业来说什么问题是重要的，怎样在官僚机构中保持生存�Q�成��业程序员的方法，怎么��h��效的思考，以及�E�序员这个职业的前途。本书的特点是各个短文简�l�易读，文中借用故事或轶事来阐明作者的观点�Q�非常具有启发性�?

12月出版，敬请��x��Q?/td>

咨询的奥�U�——成功提出和获得��的指�?/td>

�Q�Secrets of Consulting: A Guide to Giving and Getting Advice Successfully�Q?/strong>

    本书内容是关于如何更好的为别人给出徏议或接受别�h��的。作者凭借对自己25�q�专业经验�ȝ��和提��|��_�辟地归�U�_��了各�U�规则、定律和原理�Q�包括如何在竞争�Ȁ烈的咨询市场中脱颖而出�Q�如何�ؓ咨询服务定�h和拓展市场，如何衡量咨询服务的有效性以及如何处理咨询�h员与客户的关�pȝ��{�。本书深受咨询专业�h士推崇和�Ƣ迎�Q�是一本畅销多年的经典著作�?

咨询的奥�U�——咨询师的百宝箱

�Q�More Secrets of Consulting: The Consultant's Tool Kit�Q?/strong>

    本书是Gerald M. Weinberg的畅销书The Secrets of Consulting的姊妹篇�Q�在前一本书�l�出的众多定律、法则的基础上，本书�l�出了作为咨询�h员应该具有的更多的专业和个�h素质。作者通过生动的比喻，�l�合实例的简单精辟的说理�Q�列举了咨询人员应该注重培养的能力，�Ҏ��和生�z�L��度�?

2004�q�年初出版，敬请��x��Q?/td>

质量软�g��理——系�l�思维

�Q�Quality Software Management : Systems Thinking�Q?/strong>

    在本卷中�Q�Gerald M. Weinberg剖析了开发质量��Y件的�W�一个必要条�Ӟ��掌握�Q�对问题、解�{�以及质量本�w�的�Q�正��的思维�Ҏ��。其中所介绍的在��理�q�程中应该遵循的斚w��Q�可以促使我们进行这�c�d��要的思考�?

质量软�g��理——测试优�?/td>

�Q�Quality Software Management : First-Order Measurement�Q?/strong>

    该卷循序渐进��Cؓ你提供计划指��|��使你学会通过�l�致的观察与��量来收集可靠的信息。详�l�介�l�了具体的技术方法，同时�q�提供了一个模型，��复杂的��量�q�程划分为四个步骤：入口、含义、重要性和反馈。每一步都说明了在软�g开发过�E�中�Q�应该如何更为精��地�q�行观察与测量�?

质量软�g��理——协调行�?/td>

�Q�Quality Software Management : Congruent Action�Q?/strong>

    ��Z��生��出高质量的��Y�Ӟ��我们首先需要高质量的、得力的�l�理。Weinberg深受推崇的该�p�d��丛书中独立的�W�三��h��讨论的，��是如何成长��样一名经理。�ؓ了领导得力，�l�理们必��行动一致。换而言之，�q�些�l�理不仅需要对优秀软�g工作的概忉|��所理解�Q�而且�q�必��n体力行这些原理，在实践中�q�一�Ҏ��为重要�?

质量软�g��理——预期变�?/td>

�Q�Quality Software Management : Anticipating Change�Q?/strong>

    软�g企业�q�行变革的尝试往往以失败告�l�，其原因就在于对变革过�E�中的各�U�动力理解不够充�?-�q�也是企业之所以出现危机的首当其冲的一个原因。Jerry Weinberg的这本书为其包含四本独立分卷的系列丛书进行了�ȝ��Q�该卷�ؓ我们在变革过�E�中的管理工作提供了注重实效、内容翔实的最后交待�?

相关链接

· 透明�Ҏ��伯格的专访（《程序员》第9期） NEW!

· 名�h堂温伯格专栏�Q�《程序员》第8期） NEW!

· 微��Y亚洲研究院院长兼首席�U�学家张亚勤专文推荐

· 剑、气和��o狐冲

· 七宝楼台今安�?/font>

· 个体性最后的堡垒

· 走出问题的乌托邦

· 从今天开始，做你自己的上�?/font>

Copyright by shinebook, who publishes best books for IT people.
Edited by Shiningxyy,and designed by Orrin.

子弹 2008-06-17 14:08 发表评论

Project management

子弹 — Fri, 13 Jun 2008 03:23:00 GMT
     摘要: Project management From Wikipedia, the free encyclopedia Jump to: navigation, search Project Management is the discipline of planning, organizing, and managing resources to bring about the su...  阅读全文

子弹 2008-06-13 11:23 发表评论

Macadamian's Code Review Checklist

子弹 — Tue, 10 Jun 2008 06:38:00 GMT

From: http://www.macadamian.com/index.php?option=com_content&task=view&id=27&Itemid=31

Macadamian's Code Review Checklist

At Macadamian, we practice what we preach with peer code reviews. Before we commit any code to source control, we check it for compliance with this list.

We’ve made the checklist public for the use of software development teams implementing code review as part of their process. For more information about code review processes and software development best practices, read check out the Critical Path newsletter – it’s free, too!

General Code Smoke Test
Comments and Coding Conventions
Error Handling
Resource Leaks
Control Structures
Performance
Functions
Bug Fixes
Math

General Code Smoke Test

Does the code build correctly?
No errors should occur when building the source code. No warnings should be introduced by changes made to the code.

Does the code execute as expected?
When executed, the code does what it is supposed to.

Do you understand the code you are reviewing?
As a reviewer, you should understand the code. If you don't, the review may not be complete, or the code may not be well commented.

Has the developer tested the code?
Insure the developer has unit tested the code before sending it for review. All the limit cases should have been tested.

Comments and Coding Conventions

Does the code respect the project coding conventions?
Check that the coding conventions have been followed. Variable naming, indentation, and bracket style should be used.

Does the source file start with an appropriate header and copyright information?
Each source file should start with an appropriate header and copyright information. All source files should have a comment block describing the functionality provided by the file.

Are variable declarations properly commented?
Comments are required for aspects of variables that the name doesn't describe. Each global variable should indicate its purpose and why it needs to be global.

Are units of numeric data clearly stated?
Comment the units of numeric data. For example, if a number represents length, indicate if it is in feet or meters.

Are all functions, methods and classes documented?
Describe each routine, method, and class in one or two sentences at the top of its definition. If you can't describe it in a short sentence or two, you may need to reassess its purpose. It might be a sign that the design needs to be improved.

Are function parameters used for input or output clearly identified as such?
Make it clear which parameters are used for input and output.

Are complex algorithms and code optimizations adequately commented?
Complex areas, algorithms, and code optimizations should be sufficiently commented, so other developers can understand the code and walk through it.

Does code that has been commented out have an explanation?
There should be an explanation for any code that is commented out. "Dead Code" should be removed. If it is a temporary hack, it should be identified as such.

Are comments used to identify missing functionality or unresolved issues in the code?
A comment is required for all code not completely implemented. The comment should describe what's left to do or is missing. You should also use a distinctive marker that you can search for later (For example: "TODO:francis").

Error Handling

Are assertions used everywhere data is expected to have a valid value or range?
Assertions make it easier to identify potential problems. For example, test if pointers or references are valid.

Are errors properly handled each time a function returns?
An error should be detected and handled if it affects the execution of the rest of a routine. For example, if a resource allocation fails, this affects the rest of the routine if it uses that resource. This should be detected and proper action taken. In some cases, the "proper action" may simply be to log the error.

Are resources and memory released in all error paths?
Make sure all resources and memory allocated are released in the error paths.

Are all thrown exceptions handled properly?
If the source code uses a routine that throws an exception, there should be a function in the call stack that catches it and handles it properly.

Is the function caller notified when an error is detected?
Consider notifying your caller when an error is detected. If the error might affect your caller, the caller should be notified. For example, the "Open" methods of a file class should return error conditions. Even if the class stays in a valid state and other calls to the class will be handled properly, the caller might be interested in doing some error handling of its own.

Has error handling code been tested?
Don't forget that error handling code that can be defective. It is important to write test cases that exercise it.

Resource Leaks

Is allocated memory (non-garbage collected) freed?
All allocated memory needs to be freed when no longer needed. Make sure memory is released in all code paths, especially in error code paths.

Are all objects (Database connections, Sockets, Files, etc.) freed even when an error occurs?
File, Sockets, Database connections, etc. (basically all objects where a creation and a deletion method exist) should be freed even when an error occurs. For example, whenever you use "new" in C++, there should be a delete somewhere that disposes of the object. Resources that are opened must be closed. For example, when opening a file in most development environments, you need to call a method to close the file when you're done.

Is the same object released more than once?
Make sure there's no code path where the same object is released more than once. Check error code paths.

Does the code accurately keep track of reference counting?
Frequently a reference counter is used to keep the reference count on objects (For example, COM objects). The object uses the reference counter to determine when to destroy itself. In most cases, the developer uses methods to increment or decrement the reference count. Make sure the reference count reflects the number of times an object is referred.

Thread Safeness

Are all global variables thread-safe?
If global variables can be accessed by more than one thread, code altering the global variable should be enclosed using a synchronization mechanism such as a mutex. Code accessing the variable should be enclosed with the same mechanism.

Are objects accessed by multiple threads thread-safe?
If some objects can be accessed by more than one thread, make sure member variables are protected by synchronization mechanisms.

Are locks released in the same order they are obtained?
It is important to release the locks in the same order they were acquired to avoid deadlock situations. Check error code paths.

Is there any possible deadlock or lock contention?
Make sure there's no possibility for acquiring a set of locks (mutex, semaphores, etc.) in different orders. For example, if Thread A acquires Lock #1 and then Lock #2, then Thread B shouldn't acquire Lock #2 and then Lock #1.

Control Structures

Are loop ending conditions accurate?
Check all loops to make sure they iterate the right number of times. Check the condition that ends the loop; insure it will end out doing the expected number of iterations.

Is the code free of unintended infinite loops?
Check for code paths that can cause infinite loops. Make sure end loop conditions will be met unless otherwise documented.

Performance

Do recursive functions run within a reasonable amount of stack space?
Recursive functions should run with a reasonable amount of stack space. Generally, it is better to code iterative functions.

Are whole objects duplicated when only references are needed?
This happens when objects are passed by value when only references are required. This also applies to algorithms that copy a lot of memory. Consider using algorithm that minimizes the number of object duplications, reducing the data that needs to be transferred in memory.

Does the code have an impact on size, speed, or memory use?
Can it be optimized? For instance, if you use data structures with a large number of occurrences, you might want to reduce the size of the structure.

Are you using blocking system calls when performance is involved?
Consider using a different thread for code making a function call that blocks.

Is the code doing busy waits instead of using synchronization mechanisms or timer events?
Doing busy waits takes up CPU time. It is a better practice to use synchronization mechanisms.

Was this optimization really needed?
Optimizations often make code harder to read and more likely to contain bugs. Such optimizations should be avoided unless a need has been identified. Has the code been profiled?

Functions

Are function parameters explicitly verified in the code?
This check is encouraged for functions where you don't control the whole range of values that are sent to the function. This isn't the case for helper functions, for instance. Each function should check its parameter for minimum and maximum possible values. Each pointer or reference should be checked to see if it is null. An error or an exception should occur if a parameter is invalid.

Are arrays explicitly checked for out-of-bound indexes?
Make sure an error message is displayed if an index is out-of-bound.

Are functions returning references to objects declared on the stack?
Don't return references to objects declared on the stack, return references to objects created on the heap.

Are variables initialized before they are used?
Make sure there are no code paths where variables are used prior to being initialized. If an object is used by more than one thread, make sure the object is not in use by another thread when you destroy it. If an object is created by doing a function call, make sure the object was created before using it.

Does the code re-write functionality that could be achieved by using an existing API?
Don't reinvent the wheel. New code should use existing functionality as much as possible. Don't rewrite source code that already exists in the project. Code that is replicated in more than one function should be put in a helper function for easier maintenance.

Bug Fixes

Does a fix made to a function change the behavior of caller functions?
Sometimes code expects a function to behave incorrectly. Fixing the function can, in some cases, break the caller. If this happens, either fix the code that depends on the function, or add a comment explaining why the code can't be changed.

Does the bug fix correct all the occurrences of the bug?
If the code you're reviewing is fixing a bug, make sure it fixes all the occurrences of the bug.

Math

Is the code doing signed/unsigned conversions?
Check all signed to unsigned conversions: Can sign completion cause problems? Check all unsigned to signed conversions: Can overflow occur? Test with Minimum and Maximum possible values.

子弹 2008-06-10 14:38 发表评论

以下是UMLChina 参与制作的一些书�c��?

软�g工程
2002�q�《�h月神话》创下销售记�?br>2003�q�《最后期限》、《�h件》、《�h月神话》分别排在china-pub�q�度总销售榜�?�?�?�?/p>
需�?/font>

设计

久久久久亚洲av毛片大,香蕉久久夜色精品国产2020,亚洲国产小视频精品久久久三级

The Usability of Open Source Software (ZT)

Usability 101: Introduction to Usability(ZT)

Usability 101: Introduction to Usability

What (Definition of Usability)

Why Usability is Important

How to Improve Usability

When to Work on Usability

Where to Test

Learn More

Why Free Software has poor usability, and how to improve it(ZT)

Further reading

Email相关协议-SMTP

Open Source Licenses by Category

Open Source Licenses by Category

Agile Development [ZT]

Agile Development

Introduction

Continuous Integration

Stepping Stones to Continuous Integration

1. Fully Automate

2. Fast Builds

3. Lava Lamps

4. Build and Test

5. Pre-Flight Builds

Tools That Can Help

Conclusion

Enabling Agile Builds with ElectricCommander

Faster Builds, Automated Tests

About Electric Cloud

ElectricAccelerator

ElectricInsight

License

About the Author

数独�|�址

好书列表[ZT]

C++ Tips[ZT]

德鲁克的著作列表

Software quality

Project management

Macadamian's Code Review Checklist

Macadamian's Code Review Checklist