Các sơ đồ Nassi-Shneerman có thực sự được sử dụng không? [đóng cửa]


8

Tôi đã tìm hiểu về chúng trong khóa học Lập trình có cấu trúc, nhưng không bao giờ thấy chúng được sử dụng sau đó ở giai đoạn phân tích hoặc cho mục đích tài liệu. Ngay cả đối với các ngôn ngữ có cấu trúc cao như Pascal (Delphi).
Có ai trong số các bạn thực sự sử dụng sơ đồ Nassi-Shneerman không? Nếu có, bạn sử dụng công cụ nào để tạo / duy trì chúng?
chỉnh sửa:
Hoặc bạn chưa bao giờ nghe nói về họ?


6
Chưa bao giờ nghe nói về họ. Mặc dù tôi không được đào tạo chính thức về lập trình.
Chinmay Kanchi

Câu trả lời:


5

Nghe nói về sơ đồ Nassi-Shneerman, mặc dù tôi không sử dụng chúng.

Tôi không thể giúp đăng một liên kết đến thư từ chối mà Nassi và Shneerman nhận được từ Communications of ACM khi họ lần đầu tiên đề xuất sơ đồ:

http://www.cs.umd.edu/hcil/members/bshneerman/nsd/rejection_letter.html


2
Quả thực là một lá thư từ chối tàn bạo nhất. Tự hỏi anh chàng Gries đã hút thuốc gì?
stevenvh

Tôi nghĩ rằng lá thư từ chối đã làm hỏng sơ đồ dòng chảy nói chung, cho rằng lập trình có cấu trúc làm cho chúng trở nên lỗi thời. Đối với tác giả, điều này có lẽ trông giống như một trong những điều khác về biểu đồ dòng chảy.
Joey Adams

4

Chúng tôi chưa bao giờ sử dụng chúng.

Biên tập

Vâng, tôi (chúng tôi) đã nghe nói về họ. Cam ơn vi đa hỏi! :-)

Nghiêm túc mà nói, chúng tôi không sử dụng chúng. Chúng tôi thường giữ sơ đồ thành các sơ đồ dòng đơn giản, thường dễ đọc và dễ hiểu hơn.


Nhưng bạn (hoặc đồng nghiệp của bạn) đã nghe về họ?
stevenvh

3

Tôi đã nghe nói về họ và đọc một vài cuốn sách sử dụng chúng rộng rãi. Tôi nhanh chóng kết luận rằng ngay cả ngôn ngữ lắp ráp (ví dụ MIXAL trong sách của Knuth) cũng dễ hiểu hơn. Tôi chưa bao giờ có một sự thôi thúc nhỏ nhất để vẽ một cái (và không thể nhớ lại bất kỳ ai đã từng yêu cầu tôi).


1

Tôi đã sử dụng chúng. Nhưng thường xuyên hơn, tôi sử dụng một số loại mã giả khi thiết kế một thuật toán.

Bạn có thể viết mã giả với bất kỳ trình soạn thảo và kết hợp bút / giấy. Sơ đồ thường khó chỉnh sửa hơn và có xu hướng lộn xộn.

Tôi vẫn sử dụng sơ đồ UML cho thiết kế OO. Chủ yếu là lớp, nhưng đôi khi sơ đồ chuyển trạng thái cho các lớp có trạng thái phức tạp.


1

Tôi nghĩ họ thật tuyệt khi tôi bắt gặp ký hiệu vào đầu những năm 80. Nhưng nó rất gần với mã thông thường và cồng kềnh để duy trì cả sơ đồ và mã mà tôi quyết định chỉ sử dụng mã thụt lề là đủ gần với sở thích của tôi.


Thật vậy, đối với những gì các sơ đồ NS được dự định, mã giả sẽ tốt hơn và thực tế hơn nhiều.
luis.espinal

0

Vâng, tôi đã sử dụng chúng vài năm trước, nhưng trong thời đại của UML, chúng có vẻ hơi lỗi thời. Theo tôi, Nassi-Shneerman-Diagram vẫn là một loại sơ đồ tốt để trực quan hóa một khối mã có cấu trúc, tốt hơn nhiều so với Sơ đồ hoạt động UML.

Mặt khác, có thể dễ dàng hơn khi chỉ cần nhìn trực tiếp vào mã ...

Bạn có thể tìm thấy một công cụ thương mại tại đây: http://www.easycode.de/produkte.html?&L=1


0

Khi tôi mới vào đại học, một bài học chúng tôi đã có thứ so sánh và phương pháp-sơ đồ-phương pháp và sơ đồ này. Nassi-Schneerman là một người chiến thắng nhưng với một số vấn đề nhất định được nêu bật. Các điều kiện chia chiều rộng của trang nhanh chóng trở nên không thực tế, do đó, chúng tôi có thể sử dụng một đại diện giống như vậy để lặp lại. Ngoài ra, các dòng và hộp dường như dư thừa ở một mức độ nào đó.

Nghĩ về nó, và bạn sẽ nhận ra rằng những gì chúng ta đang nghiêng về cơ bản là mã giả có cấu trúc thụt vào, nhưng với một số hạn chế sử dụng các đường được vẽ xuống một bên để làm nổi bật vết lõm - hay chính xác hơn là để củng cố giả vờ rằng đó là sơ đồ.


0

Nhiều năm trước, khi tôi làm việc cho Trung tâm Hệ thống Giao thông của DOT Hoa Kỳ, tôi được giao nhiệm vụ phát triển một trình soạn thảo Nassi-Shneuman, sau đó được sử dụng để ghi lại các thiết kế phần mềm trong bộ phận.

Cá nhân, tôi không bao giờ sử dụng chúng. Tôi thích nhìn vào mã.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.