• There are many known methods of s

• There are many known methods of solution to provide a library of alternatives.
• Extensive analysis has led to explicit rules for selecting solution techniques, given problem parameters.

It is hard to see how such techniques generalize to the wider world of the ordinary software system, where cases with such neat properties are the exception. It is hard even to imagine how this breakthrough in generalization could occur.

Graphical programming. A favorite subject for PhD dissertations in software engineering is graphical, or visual, programming--the application of computer graphics to software design. [6, 7] Sometimes the promise held out by such an approach is postulated by analogy with VLSI chip design, in which computer graphics plays so fruitful a role. Sometimes the theorist justifies the approach by considering flowcharts as the ideal program-design medium and by providing powerful facilities for constructing them.

Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will.

In the first place, as I have argued elsewhere [8], the flowchart is a very poor abstraction of software structure. Indeed, it is best viewed as Burks, von Neumann, and Goldstine's attempt to provide a desperately needed high-level control language for their proposed computer. In the pitiful, multipage, connection-boxed form to which the flowchart has today been elaborated, it has proved to be useless as a design tool--programmers draw flowcharts after, not before, writing the programs they describe.

Second, the screens of today are too small, in pixels, to show both the scope and the resolution of any seriously detailed software diagram. The so-called "desktop metaphor" of today's workstation is instead an "airplane-seat" metaphor. Anyone who has shuffled a lap full of papers while seated between two portly passengers will recognize the difference--one can see only a very few things at once. The true desktop provides overview of, and random access to, a score of pages. Moreover, when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. The hardware technology will have to advance quite substantially before the scope of our scopes is sufficient for the software-design task.

More fundamentally, as I have argued above, software is very difficult to visualize. Whether one diagrams control flow, variable-scope nesting, variable cross references, dataflow, hierarchical data structures, or whatever, one feels only one dimension of the intricately interlocked software elephant. If one superimposes all the diagrams generated by the many relevant views, it is difficult to extract any global overview. The VLSI analogy is fundamentally misleading--a chip design is a layered two-dimensional description whose geometry reflects its realization in 3-space. A software system is not.

Program verification. Much of the effort in modern programming goes into testing and the repair of bugs. Is there perhaps a silver bullet to be found by eliminating the errors at the source, in the system-design phase? Can both productivity and product reliability be radically enhanced by following the profoundly different strategy of proving designs correct before the immense effort is poured into implementing and testing them?

I do not believe we will find productivity magic here. Program verification is a very powerful concept, and it will be very important for such things as secure operating-system kernels. The

technology does not promise, however, to save labor. Verifications are so much work that only a few substantial programs have ever been verified.

Kết quả (Việt) 1:

• Có rất nhiều phương pháp được biết đến của các giải pháp để cung cấp một thư viện của lựa chọn thay thế.• Phân tích rộng lớn đã dẫn đến các quy tắc rõ ràng để chọn giải pháp kỹ thuật, đưa ra tham số vấn đề.Thật khó để xem như thế nào kỹ thuật như vậy khái quát để thế giới rộng lớn hơn của hệ thống phần mềm bình thường, nơi các trường hợp với gọn gàng tài sản đó là ngoại lệ. Thật khó thậm chí để tưởng tượng như thế nào này bước đột phá trong tổng quát có thể xảy ra.Lập trình đồ họa. Một chủ đề yêu thích cho luận văn tiến sĩ trong công nghệ phần mềm là đồ họa hoặc thị giác, lập trình - ứng dụng đồ họa máy tính để thiết kế phần mềm. [6, 7] Đôi khi những lời hứa đã tổ chức ra bởi một cách tiếp cận như vậy giả thuyết bằng cách tương tự với thiết kế chip VLSI, trong những máy tính đồ họa đóng vai trò rất hiệu quả. Đôi khi nhà lý luận biện minh cho phương pháp tiếp cận bằng cách xem xét flowcharts như phương tiện thiết kế chương trình lý tưởng và bằng cách cung cấp các tiện nghi mạnh mẽ để xây dựng chúng.Không có gì thậm chí thuyết phục, ít hơn nhiều thú vị, được đã nổi lên từ những nỗ lực như vậy. Tôi đã thuyết phục rằng không có gì sẽ.Tại địa điểm đầu tiên, như tôi đã lập luận ở nơi khác [8], flowchart là một trừu tượng rất nghèo của cấu trúc phần mềm. Thật vậy, nó tốt nhất xem như Burks, von Neumann, và Goldstine của cố gắng để cung cấp một ngôn ngữ kiểm soát cao cấp tuyệt vọng cần thiết cho máy tính được đề xuất của họ. Trong các hình thức thương tâm, multipage, đóng hộp kết nối mà các flowchart vào ngày hôm nay đã được xây dựng, nó đã chứng minh là vô ích như một công cụ thiết kế - lập trình viên vẽ flowcharts sau đó, khi đó, viết các chương trình họ mô tả.Thứ hai, màn hình của ngày hôm nay là quá nhỏ, ở điểm ảnh, để hiển thị cả hai phạm vi và độ phân giải của bất kỳ sơ đồ phần mềm chi tiết nghiêm túc. Những cái gọi là "máy tính để bàn ẩn dụ" của ngày hôm nay của máy trạm thay vào đó là một ẩn dụ "máy bay chỗ ngồi". Bất cứ ai đã đi một vòng đầy đủ các giấy tờ trong khi ngồi giữa hai portly hành khách sẽ nhận ra sự khác biệt - người ta có thể thấy chỉ một rất ít những thứ cùng một lúc. Máy tính để bàn thực sự cung cấp tổng quan về, và truy cập ngẫu nhiên để, một số điểm của trang. Hơn nữa, khi phù hợp của sáng tạo chạy mạnh mẽ, nhiều hơn một lập trình viên hoặc các nhà văn đã được biết đến để từ bỏ máy tính để bàn cho sàn nhà rộng rãi hơn. Công nghệ phần cứng sẽ phải tiến khá đáng kể trước khi phạm vi phạm vi của chúng tôi là đủ cho nhiệm vụ thiết kế phần mềm.Hơn nữa, về cơ bản, như tôi đã lập luận trên, phần mềm là rất khó để hình dung. Cho dù một sơ đồ kiểm soát dòng chảy, biến phạm vi làm tổ, tài liệu tham khảo biến chéo, dataflow, cấu trúc phân cấp dữ liệu, hoặc bất cứ điều gì, một cảm giác chỉ có một kích thước của voi phần mềm phức tạp lồng. Nếu một superimposes tất cả các sơ đồ được tạo ra bởi nhiều lần xem có liên quan, nó là khó khăn để trích xuất bất kỳ tổng quan toàn cầu. Tương tự VLSI là về cơ bản là sai lầm - một thiết kế chip là một mô tả hai chiều lớp hình học mà phản ánh của nó thực hiện trong không gian 3. Một hệ thống phần mềm là không.Chương trình xác minh. Nhiều nỗ lực trong lập trình hiện đại đi vào thử nghiệm và sửa chữa lỗi. Có lẽ là một viên đạn bạc được tìm thấy bằng cách loại bỏ các lỗi tại nguồn, trong giai đoạn thiết kế hệ thống? Có thể cả năng suất và sản phẩm độ tin cậy được triệt để nâng cao bằng cách làm theo chiến lược khác nhau sâu sắc của minh thiết kế chính xác trước khi những nỗ lực bao la được đổ vào việc thực hiện và thử nghiệm chúng?Tôi không tin rằng chúng tôi sẽ tìm thấy sản xuất ma thuật ở đây. Xác minh chương trình là một khái niệm rất mạnh mẽ, và nó sẽ rất quan trọng đối với những thứ như an toàn hệ thống hoạt động hạt nhân. Các công nghệ không đảm bảo không, Tuy nhiên, để tiết kiệm lao động. Minh là rất nhiều công việc chỉ có một vài chương trình đáng kể có bao giờ được xác minh.

Kết quả (Việt) 2:

• Có rất nhiều phương pháp được biết các giải pháp cung cấp một thư viện các lựa chọn thay thế.
• Phân tích sâu rộng đã dẫn đến các quy tắc rõ ràng cho việc lựa chọn giải pháp kỹ thuật, đưa ra các thông số vấn đề. Đó là khó nhìn thấy như thế nào như kỹ thuật tổng quát hóa với thế giới rộng lớn hơn của các hệ thống phần mềm thông thường , nơi trường hợp với đặc tính gọn gàng như là ngoại lệ. Thật khó để tưởng tượng như thế nào thậm chí mang tính đột phá này trong tổng quát có thể xảy ra. Lập trình đồ họa. Một chủ đề yêu thích cho luận văn tiến sĩ về công nghệ phần mềm là đồ họa, hoặc hình ảnh, lập trình - các ứng dụng đồ họa máy tính để thiết kế phần mềm. [6, 7] Đôi khi lời hứa được tổ chức ra bởi một cách tiếp cận như vậy là mặc nhiên công nhận bằng cách tương tự với thiết kế chip VLSI, trong đó đồ họa máy tính đóng vai trò rất hiệu quả một. Đôi khi các nhà lý thuyết biện minh cho phương pháp tiếp cận bằng cách xem xét các biểu đồ như là phương tiện chương trình thiết kế lý tưởng và bằng cách cung cấp các cơ sở mạnh mẽ để xây dựng chúng. Không có gì thậm chí thuyết phục, ít nhiều thú vị, vẫn chưa nổi lên từ những nỗ lực như vậy. Tôi tin chắc rằng sẽ không có gì. Ở nơi đầu tiên, như tôi đã lập luận ở nơi khác [8], sơ đồ là một trừu tượng rất kém của cấu trúc phần mềm. Thật vậy, nó được xem tốt nhất như Burks, von Neumann, và nỗ lực Goldstine để cung cấp một ngôn ngữ rất cần điều khiển cao cấp cho máy tính đề xuất của họ. Trong nhiều trang, dạng đáng thương, kết nối đóng hộp mà các sơ đồ đã được xây dựng ngày nay, nó đã được chứng minh là vô dụng như một công cụ thiết kế - lập trình vẽ sơ đồ sau, không trước, viết các chương trình mà họ mô tả. Thứ hai, màn hình của ngày hôm nay là quá nhỏ, trong pixels, để hiển thị cả phạm vi và độ phân giải của bất kỳ phần mềm sơ đồ chi tiết nghiêm trọng. Cái gọi là "phép ẩn dụ máy tính để bàn" của các máy trạm hiện nay là thay vì một "máy bay chỗ" ẩn dụ. Bất cứ ai đã lê bước một vòng đầy đủ các giấy tờ trong khi ngồi giữa hai hành khách đẫy đà sẽ nhận ra sự khác biệt - một người có thể nhìn thấy chỉ một số rất ít những thứ cùng một lúc. Các máy tính để bàn thực sự cung cấp tổng quan về, và truy cập ngẫu nhiên, một số điểm của các trang. Hơn nữa, khi cơn của sự sáng tạo chạy mạnh mẽ, nhiều hơn một lập trình viên hoặc nhà văn đã được biết đến từ bỏ máy tính để bàn cho sàn rộng rãi hơn. Các công nghệ phần cứng sẽ phải tiến khá đáng kể trước khi phạm vi của phạm vi của chúng tôi là đủ cho các tác vụ phần mềm thiết kế. Về cơ bản, như tôi đã lập luận ở trên, phần mềm là rất khó khăn để hình dung. Cho dù một dòng sơ đồ điều khiển, biến phạm vi làm tổ, tài liệu tham khảo chéo biến, dataflow, phân cấp cấu trúc dữ liệu, hoặc bất cứ điều gì, một người cảm thấy chỉ là một mặt của các phần mềm phức tạp đan cài voi. Nếu một xếp chồng tất cả các sơ đồ được tạo ra bởi các quan điểm nhiều có liên quan, đó là khó khăn để trích xuất bất kỳ cái nhìn tổng quan toàn cầu. Các VLSI tương tự về cơ bản là gây hiểu nhầm - một thiết kế chip là một mô tả hai chiều lớp mà hình học phản ánh hiện thực của nó trong không gian 3 chiều. Một hệ thống phần mềm là không. Xác minh chương trình. Phần lớn các nỗ lực trong việc lập trình hiện đại đi vào kiểm tra và sửa chữa lỗi. Có lẽ một viên đạn bạc được tìm thấy bằng cách loại bỏ các lỗi ngay tại nguồn, trong giai đoạn hệ thống thiết kế? Có thể cả năng suất và độ tin cậy sản phẩm được triệt để nâng cao bằng cách làm theo các chiến lược sâu sắc khác nhau của minh thiết kế chính xác trước khi nỗ lực to lớn được đổ vào việc thực hiện và kiểm tra họ? Tôi không tin rằng chúng ta sẽ tìm thấy ma thuật năng suất ở đây. Chương trình xác minh là một khái niệm rất mạnh mẽ, và nó sẽ rất quan trọng cho những thứ như hạt điều hành hệ thống an toàn. Các công nghệ không hứa hẹn, tuy nhiên, để tiết kiệm lao động. Việc kiểm tra có rất nhiều công việc mà chỉ có một vài chương trình lớn đã từng được xác minh.