Bạn có thể viết một đặc tả rõ ràng bằng một ngôn ngữ tự nhiên như tiếng Anh không?


10

Đối với tôi, dường như bạn không thể viết một đặc tả phần mềm bằng tiếng Anh hoàn toàn không có sự mơ hồ, đơn giản là do bản chất không chính thức của ngôn ngữ tự nhiên - và do đó, một đặc tả thực sự rõ ràng phải bao gồm mã được viết bằng ngôn ngữ được chỉ định chính thức.

Đây là một kết quả được biết đến hoặc tôi đang thiếu một cái gì đó?


1
"mã được viết bằng một ngôn ngữ được chỉ định chính thức". Đó sẽ là toán học và logic, phải không? Đó không phải là những gì toán học và logic là dành cho? Có vẻ kỳ lạ khi hỏi, vì những ngôn ngữ này luôn tồn tại với mục đích rõ ràng là không mơ hồ. Hỏi làm gì?
S.Lott

@ S.Lott: Người dùng muốn thông số kỹ thuật bằng ngôn ngữ của họ, không phải toán học hoặc logic chính thức. Công việc của chúng tôi là dịch giữa hai miền.
tdammers

2
Mã của bạn có thể không rõ ràng, nhưng điều đó không có nghĩa là nó chính xác.
JeffO

1
@tdammers: Cái gì? Câu hỏi là về ngôn ngữ tự nhiên so với ngôn ngữ chính thức. Người dùng phải làm gì với điều này? Hơn nữa, nếu người dùng thực sự là một nhà logic học thì sao? Hơn nữa, không "nhà phân tích kinh doanh" thường viết thay mặt cho người dùng? Điều "người dùng" có vẻ đặc biệt và bên ngoài câu hỏi này.
S.Lott

@ S.Lott: Tôi đã giả sử một tình huống mà bạn phải mô tả phần mềm cho khách hàng / người dùng / các bên liên quan phi kỹ thuật khác, đó sẽ là lý do tốt nhất để sử dụng ngôn ngữ tự nhiên ngay từ đầu.
tdammers

Câu trả lời:


9

Đây không phải là điều mà luật sư luôn làm để tránh sự mơ hồ sao?

Kết quả là họ viết theo những cách không tự nhiên nhất, cố gắng đọc các bài báo của họ trở nên khó khăn hơn bao giờ hết, và mặc dù điều này luôn có sự mâu thuẫn và mơ hồ.

Bạn đã đúng, bạn không thể viết một đặc tả phần mềm hoàn toàn không có sự mơ hồ, nhưng bạn sẽ không quản lý để thực hiện một ngôn ngữ được chỉ định chính thức.

Đây cũng là lý do tại sao chúng tôi ghi lại mã của mình, vì đôi khi rất khó đọc đối với tâm trí của chúng tôi.

Không có điểm trong tài liệu mã với mã khác.


2
Một số luật sư thích che giấu và che khuất những điều. Phụ thuộc vào mục tiêu của bạn.
duffymo

1
Bạn đang nhầm lẫn luật sư với các nhà toán học.
Doc Brown

1
@Doc: Toán học chỉ là một mã khác, bởi vì chỉ các nhà toán học mới có thể đọc được nó, và không có điểm nào trong việc ghi lại mã bằng mã, đó là mật mã.
Jose Faeti

2
@Jose: Tôi muốn nói rằng bạn đang quá đơn giản. 99% tất cả các bằng chứng toán học được viết bằng ngôn ngữ tự nhiên - tất nhiên, một ngôn ngữ kỹ thuật với các thuật ngữ đặc biệt và ít nhiều sử dụng các công thức, nhưng chắc chắn không có "ngôn ngữ được chỉ định chính thức".
Doc Brown

@Doc: đó là những gì tôi đang nói ... tài liệu được viết bằng ngôn ngữ tự nhiên. Không có ý nghĩa giải thích một mã với một mã khác.
Jose Faeti

4

Không thể nào? Trước tiên hãy hỏi xem nó có mong muốn không. Nếu chúng tôi đồng ý rằng điều đó là không thể, và vẫn còn rất nhiều phần mềm hữu ích, thì mục tiêu của một đặc tả rõ ràng có vẻ mang tính học thuật.

Tôi muốn nói rằng không thể chứng minh rằng mọi thứ đều hoàn hảo và rõ ràng, cả về thông số kỹ thuật và phần mềm.

Tôi nghĩ rằng nó phụ thuộc vào kích thước của vấn đề. Nếu vấn đề đủ nhỏ, có tính chất toán học và có lẽ một số tiêu chí khác mà tôi thiếu tôi sẽ nói rằng có thể viết một đặc tả khả thi.

Vấn đề càng lớn, khán giả càng rộng thì càng khó thực hiện.

Nhưng hệ thống điện tử và các vấn đề phức tạp khác cho thấy rằng có thể viết các thông số kỹ thuật "đủ tốt" bằng tiếng Anh để giải quyết các vấn đề lớn.


2
"đủ tốt là đủ tốt, nhưng sự hoàn hảo là một PITA" - Tôi đã từng làm việc trong việc xây dựng các kiểm soát môi trường và không có thứ gì hoàn toàn rõ ràng ở đó, ngay cả khi chúng chạy tới 400 trang - đôi khi nó không thành vấn đề và trong thời gian đó, chúng tôi đã có RFI
HorusKol

4

tốt .. một đặc điểm kỹ thuật hoàn toàn rõ ràng của vấn đề là chính mã thực tế :)

Đây là vấn đề được biết đến và cho các hệ thống nhiệm vụ quan trọng đặc biệt nó là bắt buộc để viết đặc tả rõ ràng bằng một ngôn ngữ chính thức (lập trình) và sau đó chuyển đến một mã mà là provably làm những gì các đặc điểm kỹ thuật cho biết. Đây là một lĩnh vực rất hẹp, 99,999% các nhà phát triển không bao giờ phải thực hiện các nhiệm vụ như thế này, nhưng tôi đã từng nói chuyện với một người đã làm việc này cho một hệ thống kiểm soát giao thông / đường sắt.


3

Tôi là một người theo dõi W3C và tôi có xu hướng viết bài dựa trên thông số kỹ thuật của họ. Kinh nghiệm của tôi cho tôi biết rằng đọc bất kỳ đặc điểm kỹ thuật nào mà không có mã ví dụ bằng văn bản, chỉ đơn giản là đau đầu.

Tôi hoàn toàn đồng ý và tôi nghĩ lý do chính là, các nhà phát triển có xu hướng đọc và hiểu mã tốt hơn. Chỉ cần tưởng tượng bạn nhận được một bài báo toán học mà không có bất kỳ công thức.

To calculate the result, simply add variable x to variable y, 
and then divide that by the b factor.

hoặc là:

result = (x + y) / b

Cái nào ngắn hơn? Cái nào dễ đọc hơn? Cái nào mang lại sự hiểu biết nhiều hơn với nó?

Điều tương tự cũng đúng về thông số kỹ thuật. Nhiều lần, khi bạn đến các phần kỹ thuật, viết một dòng mã có thể làm rõ một đoạn giải thích dài.


Và thậm chí sau đó, tôi sẽ hỏi miền của (x + y) và (x + y) / b là gì. Họ có gấp đôi không? Họ là số nguyên? Có phải chúng là số nguyên có chiều dài vô hạn? Tôi hy vọng, nếu chúng là số nguyên, bạn đã viết các quy tắc về làm tròn :-)
xanatos

1

Giả sử có một ngôn ngữ chính thức cho phép viết các thông số kỹ thuật rõ ràng. Sau đó, tôi đề xuất rằng nên có một ánh xạ phỏng đoán cho một tập hợp con của tiếng Anh. Do đó, có thể viết các thông số kỹ thuật rõ ràng nếu bạn dính vào tập hợp con này.

Nhưng bất kỳ ngôn ngữ chính thức nào đủ sức biểu cảm để làm bất cứ điều gì thú vị sẽ không có sự mâu thuẫn (không hoàn hảo của Godel).


Tôi chắc chắn rằng lý luận là mơ hồ vì nó bằng tiếng Anh đơn giản. Bạn có thể viết nó bằng một ngôn ngữ chính thức?
blubb

1
Tôi tin rằng đây là giả định của bạn: citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.88.1151
Thomas Owens

Và sau đó, có một vấn đề tạm dừng, chuyển thành sự mơ hồ: N lớn hơn N bởi 1 không định nghĩa N
mojuba

1
-1 vì nhận định lý của Goddels.
Ingo

1

Thông số kỹ thuật là mơ hồ và không chính xác bởi vì mọi người mơ hồ và không chính xác. Tìm một người hoàn hảo và có lẽ sau đó bạn có thể có được một đặc điểm kỹ thuật hoàn hảo.

Tiếng Anh, tiếng Swirin, tiếng Phạn hoặc tiếng Babylon không có sự khác biệt.


1

Sự mơ hồ thực sự là một thế mạnh trong bối cảnh này.

Để giải thích tại sao, chúng ta hãy giả định trong một khoảnh khắc mà nó có thể sử dụng ngôn ngữ tiếng Anh trong một cách hoàn toàn rõ ràng, do đó bất kỳ vấn đề có thể được giải quyết theo lập trình có thể được thể hiện hoàn toàn và rõ ràng. Nếu chúng ta sử dụng biến thể tiếng Anh này và mô tả của chúng tôi thực sự mô tả chương trình được viết hoàn toàn và rõ ràng, thì nó sẽ theo logic một cách hợp lý để có thể thực hiện dịch tự động sang ngôn ngữ lập trình đích - nói cách khác, biến thể của Tiếng Anh chúng tôi đã quan niệm thực sự là một ngôn ngữ lập trình.

Những người đọc tài liệu thiết kế (đặc biệt là thiết kế chức năng) thực sự không muốn mức độ chi tiết này - đọc nguồn của chương trình, cho dù bằng tiếng C ++, Java hoặc tiếng Anh không rõ ràng, vượt quá đầu người không lập trình trung bình. Đây là nơi các ngôn ngữ tự nhiên xuất hiện: chúng cho phép người viết một đặc tả trượt theo tỷ lệ chi tiết, chuyển các chi tiết triển khai không liên quan vào ẩn ý hoặc để chúng hoàn toàn không xác định. Ngôn ngữ tự nhiên có đầy đủ các thiết bị để truyền đạt ý nghĩa tương đối rõ ràng mặc dù bạn không cung cấp một định nghĩa chính xác (đó là một phần của những bản dịch tự động rất khó).

Vì vậy, mục tiêu thường không phải là một thông số đầy đủ, chính xác và rõ ràng; mục tiêu là viết một thông số minh họa rõ ràng, cho con người, những gì bạn sắp xây dựng.

Bất cứ khi nào bạn cần chính xác và không mơ hồ, và dù sao mọi thứ cũng trở nên kỹ thuật, mã giả thường có giá trị hơn ngôn ngữ tự nhiên hoặc ngôn ngữ chính thức cứng nhắc - nó vẫn có thể bỏ qua các chi tiết không liên quan (bằng cách gọi các hàm / quy trình không xác định), nhưng cấu trúc không rõ ràng .


0

Bạn không thiếu thứ gì, ngoại trừ tài liệu đó được viết cho con người đọc. Một số sự mơ hồ được mong đợi, và thậm chí được hoan nghênh, bởi vì văn bản ngắn gọn rất khó đọc (= không dành cho con người).

Việc chỉ định tài liệu cho một ngôn ngữ chính thức bằng một ngôn ngữ chính thức khác sẽ là một loại vấn đề trứng gà.

Nếu bạn thực sự cần đặc tả chính thức, thì có những cách chính thức để kiểm tra mô hình . Đây là một lĩnh vực nghiên cứu tích cực và rất thú vị, nhưng "người dùng" cuối cùng ở đây là máy móc, không phải con người.


0

(Một số điểm của tôi đã được ám chỉ bởi các câu trả lời khác, nhưng tôi cảm thấy rằng tôi đang cung cấp một quan điểm đủ khác để làm cho câu trả lời này có giá trị hơn là một nhận xét.)

Trước khi chúng tôi giải quyết vấn đề liệu một đặc điểm kỹ thuật có thể được thực sự và hoàn toàn rõ ràng, chúng ta phải giải quyết các câu hỏi liệu nó nên được rõ ràng, ít nhất là ở mức độ mà bạn đang hỏi về.

Hãy để tôi tiếp cận điều này từ quan điểm của một người quản lý chương trình làm việc trong một dự án vừa và nhỏ, hoặc một tính năng như một phần của dự án lớn hơn. Thường có hai loại thông số kỹ thuật khác nhau sẽ được viết cho một dự án như vậy: đặc tả Chức năng (hoặc PM) và đặc tả Thiết kế (hoặc Dev):

  • Đặc tả chức năng có công việc mô tả những gì dự án hoặc tính năng nên làm, thường là từ quan điểm của khách hàng. Nói chung, nó không nên mô tả làm thế nào điều này nên được thực hiện. Tùy thuộc vào loại dự án, khách hàng có thể quan tâm API trông như thế nào, nhưng khách hàng có quan tâm liệu lớp A có kế thừa từ lớp B hoặc thực hiện giao diện C không? Anh không nên. Và cũng không nên đặc tả chức năng. Điều này đã giới thiệu một mức độ mơ hồ: đó là thiết kế kỹ thuật.
  • Đặc tả thiết kế có nhiệm vụ mô tả cách đáp ứng các yêu cầu chức năng, từ quan điểm của kiến ​​trúc sư hoặc nhà thiết kế kỹ thuật của tính năng hoặc dự án. Nó được dự định để giải quyết sự mơ hồ cấp cao của thiết kế kỹ thuật. Điều này sẽ chứa những chi tiết mà bạn không muốn trong đặc tả chức năng, chẳng hạn như kiến ​​trúc của giải pháp, bao gồm cấu trúc lớp, kế thừa, thậm chí có thể là các hàm và phương thức riêng lẻ, tùy thuộc vào phạm vi và quy mô của dự án. Kiến trúc sư có quan tâm đến những gì bạn gọi các biến tạm thời của bạn hoặc liệu bạn có sử dụng danh sách hoặc mảng cho kiểu dữ liệu nội bộ không? Giả sử cô ấy tin tưởng các nhà phát triển của mình, cô ấy không nên và đặc điểm kỹ thuật thiết kế cũng không nên. Điều này giới thiệu một mức độ mơ hồ thứ hai: đó là việc thực hiện.

Nói chung, các chi tiết cấp độ thực hiện này không được ghi lại trong một tài liệu chính thức, mà là tài liệu, theo từng se , trong chính mã, bao gồm cả các ý kiến. Mức độ mơ hồ này cho phép một nhà phát triển giỏi sử dụng các kỹ năng của chính mình và đưa ra các quyết định kỹ thuật định hướng chi tiết là đặc trưng của một nhà phát triển cá nhân tốt. Bởi vì điều này, tôi sẽ không ngần ngại nói rằng sự mơ hồ trong một đặc tả thực tế là một điều tốt: nó cho phép các nhà phát triển thực hiện công việc của họ và nâng chúng lên trên "khỉ mã".

Tuy nhiên, điều này không có nghĩa là cần có sự mơ hồ trong toàn bộ tài liệu. Ở cấp độ cao, không nên có sự mơ hồ về giao diện với khách hàng. Nếu tính năng này có API hướng tới công chúng, thì nó phải được xác định nghiêm ngặt. Nếu hệ thống yêu cầu một ngày được thông qua để thực hiện công việc của nó, ngày này có nên theo múi giờ địa phương hoặc UTC không? Định dạng nào là cần thiết? Nó cần phải chính xác đến mili giây, hay là phút tốt?

Quay trở lại câu hỏi liệu ngôn ngữ tự nhiên có thể được sử dụng để tạo ra các thông số kỹ thuật rõ ràng hay không, sự thật là nó không tốt trong việc nắm bắt mức độ rõ ràng này. Tôi đã thấy nó được thực hiện trong một số trường hợp hạn chế nhất định, nhưng đó có thể là những ngoại lệ duy nhất mà chúng ta không thể áp dụng phổ biến. Thông thường, sự mơ hồ được giải quyết với sự trợ giúp của thuật ngữ kỹ thuật, sơ đồ hoặc thậm chí là mã giả. Khi bạn bắt đầu tranh thủ sự giúp đỡ của các công cụ như vậy, ngôn ngữ tự nhiên không còn là mô tả duy nhất. Bởi vì các công cụ này có thể làm cho ngay cả một đặc điểm kỹ thuật hoàn toàn rõ ràng về chức năng rõ ràng hơn nhiều, tôi sẽ mạo hiểm nói rằng một cam kết như vậy thậm chí không nên được thử.

Phải nói rằng, bởi vì ngôn ngữ tự nhiên thường được bổ sung bởi các công cụ này để làm cho nó hoạt động rõ ràng, theo ý kiến ​​chuyên môn của tôi rằng không, chỉ riêng ngôn ngữ tự nhiên là không đủ để tạo ra các thông số kỹ thuật rõ ràng trong mọi trường hợp.


0

Người ta có thể làm cho ngôn ngữ tự nhiên tương đối rõ ràng, nhưng chỉ với khó khăn lớn.

Nghề luật pháp rất cần ngôn ngữ để rõ ràng nhất có thể. Mặc dù nhiều về cách áp dụng luật có thể được mở để giải thích, nhưng những từ này có nghĩa là gì không nên.

Điều này cần dẫn đến việc phát minh ra hợp pháp. Bạn sẵn sàng đi bao xa?


0

Có một số thông số kỹ thuật của nhóm mở, ISO, IETF và ITU đủ rõ ràng để các công ty cạnh tranh cao có thể hợp tác khá thành công. Có một số thông số kỹ thuật là cơ sở của hợp đồng hoặc luật pháp mà hàng triệu đô la đang bị đe dọa.

Vì vậy, thông số kỹ thuật có thể không "hoàn hảo". Tuy nhiên đó là vì con người không hoàn hảo. Ví dụ, không rõ ràng rằng HTTP nên sử dụng tiêu đề "Người giới thiệu" - cách viết đúng trong thực tế là "Người giới thiệu".

Ngôn ngữ tiếng Anh có khả năng không mơ hồ, nhưng con người có khả năng mắc lỗi - bao gồm cả sự mơ hồ.

Ngoài ra, có thể hữu ích khi mơ hồ có chủ ý cho các chi tiết chưa được hoàn thiện hoặc có thể cần được cập nhật trong tương lai. Ví dụ: một đặc tả có thể chỉ định "băm" thay vì chỉ định cụ thể md5, sha1, crc32, v.v.


0

Tôi tin rằng câu trả lời đúng là tiêu cực. Cần phân biệt các câu hỏi sau:

  1. Có thể viết một đặc tả phần mềm bằng ngôn ngữ tự nhiên không chứa sự mơ hồ?
  2. Có thể viết phần mềm bằng ngôn ngữ tự nhiên không chứa sự mơ hồ?

Sự khác biệt giữa câu hỏi thứ nhất và câu hỏi thứ hai liên quan đến mức độ chi tiết liên quan, mức độ giải thích cần thiết và các quy tắc áp đặt cho việc xây dựng câu trong ngôn ngữ tự nhiên cho mục đích viết phần mềm hoặc đặc tả phần mềm.

Câu trả lời cho câu hỏi thứ hai là khẳng định. Đưa ra một tập hợp con bị ràng buộc phù hợp của một ngôn ngữ tự nhiên với các quy tắc đã được thống nhất để xây dựng câu và ý nghĩa, mã có thể được viết bằng các câu tiếng Anh ngữ pháp. Chẳng hạn, ngôn ngữ sau đây rõ ràng cho phép viết câu lệnh gán:

Variables: x,y,z,...
Constants: 1,2,3,...
Rules: (1) if x is a variable and n a constant, then
           "The variable x contains the number n" is a sentence.
       (2) if x is a variable and n a constant, then
           "Assign the number n to the variable x" is a sentence.

Đó là, chúng ta có thể dịch một cách có hệ thống mã được viết bằng ngôn ngữ lập trình chính thức sang ngôn ngữ tự nhiên bằng cách mô tả từng thủ tục. Mặt khác, một đặc tả phần mềm thường yêu cầu giải thích. Do đó, việc một đặc tả phần mềm có thể được cung cấp rõ ràng hay không phụ thuộc vào mức độ chi tiết liên quan đến đặc tả. Tuy nhiên, với một miền được chọn trong đó phạm vi thông số kỹ thuật, với các hoạt động cụ thể trên miền này được chọn, có thể thực hiện quy trình dịch tương tự. Ví dụ:

Over the domain D supporting operations f,g,h over elements a,b,c in relations
P,R,Q with properties φ,ψ,θ, design a program that does X,Y,Z.

trường hợp báo cáo X, Y, Zchỉ chứa những mặt hàng nêu tại lời nói đầu của đặc điểm kỹ thuật và được viết bằng một hình thức phù hợp và thỏa thuận tập hợp con của một ngôn ngữ tự nhiên. Sự mơ hồ sau đó sẽ liên quan đến cách thực hiện đặc tả - nhưng điều này sẽ được dự kiến.


0

Không

Một đặc điểm kỹ thuật rõ ràng của một tính toán là một chương trình máy tính.

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.