คุณสามารถเขียนข้อกำหนดที่ชัดเจนในภาษาธรรมชาติเช่นภาษาอังกฤษได้ไหม

สำหรับฉันแล้วคุณไม่สามารถเขียนข้อกำหนดซอฟต์แวร์เป็นภาษาอังกฤษที่ปราศจากความกำกวมได้อย่างสมบูรณ์เนื่องจากลักษณะที่ไม่เป็นทางการของภาษาธรรมชาติ - และดังนั้นข้อกำหนดเฉพาะที่ชัดเจนจะต้องมีรหัสที่เขียนในภาษาที่ระบุอย่างเป็นทางการ

นี่เป็นผลลัพธ์ที่ทราบหรือฉันขาดอะไรไปหรือเปล่า

นี่คือสิ่งที่นักกฎหมายทำเพื่อหลีกเลี่ยงความคลุมเครือหรือไม่?

ผลที่ได้คือพวกเขาเขียนด้วยวิธีที่ผิดธรรมชาติมากที่สุดการพยายามอ่านเอกสารของพวกเขานั้นยากกว่าที่เคยและถึงแม้ว่าจะมีความขัดแย้งและความกำกวมอยู่เสมอ

คุณถูกต้องคุณไม่สามารถเขียนข้อกำหนดซอฟต์แวร์ที่ปราศจากความกำกวมได้อย่างสมบูรณ์ แต่คุณจะไม่สามารถดำเนินการได้ด้วยการใช้ภาษาที่ระบุอย่างเป็นทางการ

นี่คือเหตุผลที่เราจัดทำเอกสารรหัสของเราเพราะบางครั้งมันยากที่จะอ่านสำหรับจิตใจของเรา

ไม่มีจุดในการบันทึกรหัสด้วยรหัสอื่น

เป็นไปไม่ได้? ลองถามว่ามันเป็นที่น่าพอใจก่อนหรือไม่ หากเรายอมรับว่ามันเป็นไปไม่ได้และยังมีซอฟต์แวร์ที่มีประโยชน์มากมายอยู่ตรงนั้นเป้าหมายของข้อกำหนดที่ชัดเจนนั้นดูเหมือนว่าเป็นเรื่องวิชาการ

ฉันจะบอกว่ามันเป็นไปไม่ได้ที่จะพิสูจน์ว่ามีอะไรที่สมบูรณ์แบบและไม่คลุมเครือทั้งสำหรับสเป็คและซอฟต์แวร์

ฉันคิดว่ามันขึ้นอยู่กับขนาดของปัญหา หากปัญหามีขนาดเล็กเพียงพอคณิตศาสตร์ในธรรมชาติและอาจมีเกณฑ์อื่น ๆ ที่ฉันขาดไปฉันจะบอกว่าเป็นไปได้ที่จะเขียนข้อกำหนดที่ใช้งานได้

ยิ่งปัญหาใหญ่ขึ้นเท่าใดผู้ชมก็จะยิ่งยากขึ้นเท่านั้น

แต่ avionics และปัญหาที่ซับซ้อนอื่น ๆ แนะนำว่าเป็นไปได้ที่จะเขียนข้อกำหนด "ดีพอ" เป็นภาษาอังกฤษเพื่อแก้ปัญหาใหญ่

ดี .. สเปคที่ชัดเจนของปัญหาคือโค้ดจริง ๆ :)

นี่เป็นปัญหาที่ทราบกันดีและสำหรับระบบวิกฤตภารกิจพิเศษที่จำเป็นต้องเขียนข้อกำหนดที่ชัดเจนในภาษาทางการ (การเขียนโปรแกรม) แล้วแปลงให้เป็นรหัสที่พิสูจน์ได้ในสิ่งที่ข้อกำหนดระบุ นี่เป็นสนามที่แคบมากนักพัฒนา 99.999% ไม่เคยทำงานแบบนี้มาก่อน แต่ฉันเคยคุยกับผู้ชายที่ทำสิ่งนี้เพื่อควบคุมการจราจร / ระบบรถไฟ

ฉันเป็นคนติดตาม W3C และฉันมักจะเขียนบทความตามข้อกำหนดของพวกเขา ประสบการณ์ของฉันบอกฉันว่าการอ่านสเปคใด ๆ โดยไม่ต้องเขียนโค้ดตัวอย่างเป็นเรื่องปวดหัว

ฉันเห็นด้วยอย่างสมบูรณ์และฉันคิดว่าเหตุผลหลักคือผู้พัฒนามักจะอ่านและเข้าใจโค้ดได้ดีขึ้น แค่คิดว่าคุณได้รับกระดาษคณิตศาสตร์โดยไม่มีสูตรใด ๆ

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

หรือ:

result = (x + y) / b

อันไหนสั้นกว่ากัน? อันไหนที่อ่านได้มากกว่า? ซึ่งนำมาซึ่งความเข้าใจที่มากขึ้นกับมัน?

เช่นเดียวกับข้อมูลจำเพาะ หลายครั้งที่คุณไปถึงส่วนทางเทคนิคการเขียนรหัสหนึ่งบรรทัดสามารถอธิบายย่อหน้ายาว ๆ ของคำอธิบาย

สมมติว่ามีภาษาเป็นทางการที่อนุญาตให้เขียนข้อกำหนดที่ชัดเจน จากนั้นฉันเสนอว่าควรมีการทำแผนที่ bijective กับเซตย่อยของภาษาอังกฤษ ดังนั้นจึงเป็นไปได้ที่จะเขียนข้อมูลจำเพาะที่ไม่ชัดเจนหากคุณติดกับชุดย่อยนี้

แต่ภาษาทางการใด ๆ ที่แสดงออกได้มากพอที่จะทำสิ่งที่น่าสนใจจะไม่เป็นอิสระ (Gödelไม่สมบูรณ์)

ข้อมูลจำเพาะมีความคลุมเครือและไม่แน่ชัดเพราะผู้คนคลุมเครือและไม่แน่นอน ค้นหาบุคคลที่สมบูรณ์แบบและบางทีคุณอาจได้คุณสมบัติที่สมบูรณ์แบบ

ภาษาอังกฤษ, ภาษาสวาฮิลี, สันสกฤตหรือบาบิโลนไม่ได้สร้างความแตกต่าง

ความกำกวมนั้นเป็นจุดแข็งในบริบทนี้

เพื่ออธิบายว่าทำไมลองสมมติว่าเป็นไปได้ที่จะใช้ภาษาอังกฤษในลักษณะที่ไม่คลุมเครืออย่างสมบูรณ์ดังนั้นปัญหาใด ๆ ที่สามารถแก้ไขได้โดยทางโปรแกรมสามารถแสดงออกได้อย่างสมบูรณ์และไม่น่าสงสัย หากเราใช้ตัวแปรภาษาอังกฤษนี้และคำอธิบายของเราไม่ได้อธิบายถึงโปรแกรมที่จะเขียนอย่างสมบูรณ์และไม่น่าสงสัยแล้วมันจะเป็นไปตามหลักเหตุผลว่าจะต้องทำการแปลอัตโนมัติเป็นภาษาโปรแกรมเป้าหมาย - กล่าวอีกนัยหนึ่งคือ ภาษาอังกฤษที่เราคิดว่าเป็นภาษาโปรแกรมเอง

ผู้ที่อ่านเอกสารการออกแบบ (โดยเฉพาะการออกแบบฟังก์ชั่น) ไม่ต้องการรายละเอียดในระดับนี้จริง ๆ - การอ่านซอร์สของโปรแกรมไม่ว่าจะเป็น C ++, Java หรือ Unambiguous English นั้นอยู่เหนือหัวของผู้ที่ไม่ใช่โปรแกรมเมอร์ นี่คือที่มาของภาษาธรรมชาติ: อนุญาตให้ผู้เขียนสเปคเลื่อนไปทางใดก็ได้ในระดับรายละเอียดย้ายรายละเอียดการใช้งานที่ไม่เกี่ยวข้องไปเป็นส่วนย่อยหรือปล่อยให้พวกเขาไม่ได้ระบุอย่างสมบูรณ์ ภาษาธรรมชาติเต็มไปด้วยอุปกรณ์ที่สื่อความหมายได้ค่อนข้างชัดเจนแม้ว่าคุณจะไม่ได้ให้คำจำกัดความที่แน่นอน (ซึ่งเป็นส่วนหนึ่งของสิ่งที่ทำให้การแปลอัตโนมัติยากมาก)

ดังนั้นเป้าหมายจึงไม่ใช่ข้อมูลจำเพาะที่สมบูรณ์ถูกต้องและชัดเจน เป้าหมายคือการเขียนสเป็คที่แสดงให้เห็นชัดเจนถึงมนุษย์สิ่งที่คุณกำลังจะสร้าง

เมื่อใดก็ตามที่คุณต้องการความถูกต้องและไม่คลุมเครือและสิ่งต่าง ๆ กำลังได้รับทางเทคนิค pseudocode มักจะมีค่ามากกว่าภาษาธรรมชาติหรือเป็นทางการที่เข้มงวด - มันยังสามารถทิ้งรายละเอียดที่ไม่เกี่ยวข้องได้ (โดยการเรียกฟังก์ชั่น / กระบวนการที่ไม่เจาะจง) .

คุณไม่ได้หายไปเลยยกเว้นว่ามีการเขียนเอกสารให้มนุษย์อ่าน คาดหวังความคลุมเครือบางอย่างและยินดีต้อนรับเพราะข้อความสั้น ๆ อ่านยาก (= ไม่ใช่สำหรับมนุษย์)

การระบุเอกสารสำหรับภาษาที่เป็นทางการในอีกภาษาที่เป็นทางการจะเป็นปัญหาของไก่และไข่

หากคุณต้องการสเปคอย่างเป็นทางการจริงๆแล้วมีวิธีการอย่างเป็นทางการของรุ่นการตรวจสอบ มันเป็นงานวิจัยที่กระตือรือร้นและน่าสนใจ แต่ท้ายที่สุด "ผู้ใช้" ที่นี่คือเครื่องจักรไม่ใช่มนุษย์

(บางประเด็นของฉันได้รับการกล่าวถึงโดยคำตอบอื่น ๆ แล้ว แต่ฉันรู้สึกว่าฉันกำลังให้มุมมองที่แตกต่างพอที่จะทำให้คำตอบนี้มีค่ามากกว่าความคิดเห็น)

ก่อนที่เราจะจัดการกับปัญหาว่าข้อมูลจำเพาะสามารถเป็นจริงและไม่คลุมเครืออย่างสมบูรณ์หรือไม่เราต้องตอบคำถามว่าควรจะมีความโปร่งใสหรือไม่อย่างน้อยในระดับที่คุณต้องการ

ให้ฉันเข้าใกล้สิ่งนี้จากมุมมองของผู้จัดการโปรแกรมที่ทำงานในโครงการขนาดเล็กถึงขนาดกลางหรือคุณลักษณะเป็นส่วนหนึ่งของโครงการขนาดใหญ่ โดยปกติจะมีสองประเภทที่แตกต่างกันของข้อกำหนดที่จะถูกเขียนขึ้นสำหรับโครงการดังกล่าวคือการทำงาน (หรือ PM) สเปคและการออกแบบ (หรือ Dev) สเปค:

• ฟังก์ชั่นการใช้งานมีหน้าที่อธิบายสิ่งที่โปรเจคหรือฟีเจอร์ควรทำซึ่งมักมาจากมุมมองของลูกค้า โดยทั่วไปไม่ควรอธิบายว่าควรทำอย่างไร ขึ้นอยู่กับประเภทของโครงการลูกค้าอาจสนใจว่า API ที่หันหน้าไปทางภายนอกนั้นเป็นอย่างไร แต่ลูกค้าสนใจว่า Class A สืบทอดจากคลาส B หรือใช้อินเตอร์เฟส C หรือไม่ เขาไม่ควร และไม่ควรกำหนดคุณสมบัติการทำงาน สิ่งนี้นำเสนอความคลุมเครือในระดับหนึ่ง: การออกแบบทางเทคนิค
• ข้อกำหนดการออกแบบมีหน้าที่อธิบายว่าควรปฏิบัติตามข้อกำหนดด้านการทำงานอย่างไรจากมุมมองของสถาปนิกหรือนักออกแบบด้านเทคนิคของคุณสมบัติหรือโครงการ มีวัตถุประสงค์เพื่อแก้ไขความคลุมเครือระดับสูงของการออกแบบทางเทคนิค สิ่งนี้จะมีรายละเอียดเหล่านั้นที่คุณไม่ต้องการในข้อกำหนดคุณสมบัติการทำงานเช่นสถาปัตยกรรมของโซลูชันรวมถึงโครงสร้างของคลาสการสืบทอดบางทีแม้แต่ฟังก์ชันและเมธอดแต่ละตัวขึ้นอยู่กับขอบเขตและขนาดของโครงการ สถาปนิกสนใจสิ่งที่คุณเรียกตัวแปรชั่วคราวของคุณหรือไม่ว่าคุณจะใช้รายการหรืออาร์เรย์สำหรับประเภทข้อมูลภายในหรือไม่ สมมติว่าเธอไว้วางใจนักพัฒนาของเธอเธอไม่ควรและไม่ควรกำหนดรายละเอียดการออกแบบ สิ่งนี้นำเสนอระดับที่สองของความคลุมเครือ: ของการนำไปใช้

โดยทั่วไปรายละเอียดระดับการใช้งานเหล่านี้จะไม่ถูกบันทึกในเอกสารที่เป็นทางการ แต่มีการจัดทำเป็นเอกสาร แต่ต่อรหัสในตัวของมันเองรวมถึงความคิดเห็น ความคลุมเครือในระดับนี้ช่วยให้นักพัฒนาซอฟต์แวร์ที่ดีสามารถใช้ทักษะของตนเองและทำการตัดสินใจเชิงเทคนิคโดยมีรายละเอียดซึ่งเป็นจุดเด่นของนักพัฒนาที่ดี ด้วยเหตุนี้ฉันจะไม่ลังเลที่จะพูดว่าความกำกวมในสเปคคือในความเป็นจริงสิ่งที่ดี: มันช่วยให้นักพัฒนาสามารถทำงานของพวกเขาและยกพวกเขาเหนือ "รหัสลิง"

อย่างไรก็ตามสิ่งนี้ไม่ได้บอกว่าควรมีความกำกวมผ่านเอกสารทั้งหมด ในระดับสูงไม่ควรมีความกำกวมเกี่ยวกับอินเทอร์เฟซกับลูกค้า หากสถานที่นั้นมีสาธารณะ API ควรมีการกำหนดอย่างเคร่งครัด หากระบบต้องการให้มีการส่งผ่านวันที่เพื่อให้ทำงานได้วันที่นี้ควรอยู่ในเขตเวลาท้องถิ่นหรือ UTC? รูปแบบใดที่จำเป็น? จำเป็นต้องมีความแม่นยำต่อมิลลิวินาทีหรือไม่หรือเป็นนาทีที่ดี?

กลับมาที่คำถามที่ว่าภาษาธรรมชาติสามารถใช้เพื่อสร้างข้อกำหนดที่ชัดเจนได้หรือไม่เป็นความจริงที่ว่ามันไม่ดีมากในการจับภาพความคมชัดระดับนี้ ฉันเคยเห็นมันทำในบางสถานการณ์ที่ จำกัด แต่ก็มีข้อยกเว้นที่ไม่เหมือนใครซึ่งเราไม่สามารถนำไปใช้ได้ในระดับสากล ส่วนใหญ่แล้วความคลุมเครือจะได้รับการแก้ไขด้วยความช่วยเหลือของศัพท์แสงทางเทคนิคไดอะแกรมหรือแม้แต่ pseudocode เมื่อคุณเริ่มเกณฑ์ความช่วยเหลือของเครื่องมือดังกล่าวภาษาธรรมชาติจะสิ้นสุดลงเพื่อเป็นตัวบ่งชี้เพียงอย่างเดียว เนื่องจากเครื่องมือเหล่านี้สามารถทำให้ข้อมูลจำเพาะที่ชัดเจนในการใช้งานชัดเจนยิ่งขึ้นฉันจึงกล้าที่จะบอกว่าการทำเช่นนั้นไม่ควรพยายาม

ต้องบอกว่าเนื่องจากภาษาธรรมชาติโดยทั่วไปจะเสริมด้วยเครื่องมือเหล่านี้เพื่อให้มันใช้งานได้อย่างชัดเจนมันเป็นความคิดเห็นของมืออาชีพของฉันที่ไม่มีภาษาธรรมชาติเพียงอย่างเดียวไม่เพียงพอที่จะสร้างข้อกำหนดที่ชัดเจนในทุกกรณี

เราสามารถทำให้ภาษาธรรมชาติค่อนข้างคลุมเครือ แต่มีปัญหามาก

อาชีพนักกฎหมายค่อนข้างต้องการภาษาที่ชัดเจนที่สุดเท่าที่จะเป็นไปได้ ในขณะที่เกี่ยวกับวิธีการที่กฎหมายถูกนำไปใช้อาจเปิดให้มีการตีความสิ่งที่คำว่าหมายถึงไม่ควร

ความต้องการนี้นำไปสู่การประดิษฐ์นักกฎหมาย คุณเต็มใจไปไกลแค่ไหน?

มีข้อกำหนดจำนวนหนึ่งโดยกลุ่ม open, ISO, IETF และ ITU ที่ไม่มีความชัดเจนเพียงพอสำหรับ บริษัท ที่มีการแข่งขันสูงเพื่อให้สามารถทำงานร่วมกันได้สำเร็จ มีข้อกำหนดจำนวนหนึ่งที่เป็นพื้นฐานของสัญญาหรือกฎหมายที่มีเงินเดิมพันหลายล้านดอลลาร์

ดังนั้นข้อกำหนดอาจไม่ "สมบูรณ์" อย่างไรก็ตามนั่นเป็นเพราะมนุษย์ไม่ได้สมบูรณ์แบบ ตัวอย่างเช่นมันไม่ชัดเจนว่า HTTP ควรใช้ส่วนหัว "อ้างอิง" - การสะกดที่ถูกต้องในความเป็นจริง "อ้างอิง"

ภาษาอังกฤษมีความสามารถในการกำกวม แต่มนุษย์มีความสามารถในการทำผิดพลาด - รวมถึงความกำกวม

นอกจากนี้อาจเป็นประโยชน์หากมีความคลุมเครืออย่างจงใจเพื่อดูรายละเอียดที่ยังไม่สิ้นสุดหรืออาจจำเป็นต้องได้รับการปรับปรุงในอนาคต ตัวอย่างเช่นข้อมูลจำเพาะอาจระบุ "แฮช" แทนที่จะระบุ md5, sha1, crc32 เป็นต้นโดยเฉพาะ

ฉันเชื่อว่าคำตอบที่ถูกต้องเป็นลบ จำเป็นต้องแยกแยะคำถามต่อไปนี้:

1. เป็นไปได้หรือไม่ที่จะเขียนข้อกำหนดซอฟต์แวร์ในภาษาธรรมชาติที่ไม่มีความคลุมเครือ?
2. เป็นไปได้หรือไม่ที่จะเขียนซอฟต์แวร์ด้วยภาษาธรรมชาติที่ไม่มีความคลุมเครือ?

ความแตกต่างระหว่างคำถามที่หนึ่งและคำถามที่สองเกี่ยวข้องกับระดับของรายละเอียดที่เกี่ยวข้องจำนวนของการตีความที่จำเป็นและกฎที่กำหนดในการสร้างประโยคในภาษาธรรมชาติเพื่อวัตถุประสงค์ในการเขียนซอฟต์แวร์หรือซอฟต์แวร์สเปค

คำตอบสำหรับคำถามที่สองคือการยืนยัน ให้เซตย่อยที่เหมาะสมของภาษาธรรมชาติกับกฎที่ตกลงกันไว้สำหรับการสร้างประโยคและความหมายรหัสสามารถเขียนในประโยคไวยากรณ์ภาษาอังกฤษ ตัวอย่างเช่นภาษาต่อไปนี้อนุญาตให้เขียนคำสั่งการมอบหมายอย่างไม่น่าสงสัย:

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.

นั่นคือเราสามารถแปลโค้ดที่เขียนด้วยภาษาทางการที่เป็นทางการเป็นภาษาธรรมชาติโดยการอธิบายแต่ละขั้นตอน ในทางกลับกันข้อกำหนดซอฟต์แวร์มักจะต้องมีการตีความ ดังนั้นไม่ว่าจะเป็นข้อกำหนดซอฟต์แวร์ที่สามารถให้ได้อย่างชัดเจนขึ้นอยู่กับระดับของรายละเอียดที่เกี่ยวข้องในข้อกำหนด อย่างไรก็ตามเนื่องจากโดเมนที่เลือกซึ่งมีข้อกำหนดอยู่ในช่วงโดยมีการดำเนินการเฉพาะในโดเมนนี้ที่เลือกไว้จึงสามารถดำเนินการกระบวนการแปลที่คล้ายกันได้ ตัวอย่างเช่น

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.

ที่งบX, Y, Zมีเฉพาะรายการที่ระบุไว้ในคำนำข้อกำหนดและเขียนในอย่างเป็นทางการและเหมาะสมตามที่ตกลงย่อยของภาษาธรรมชาติ ความคลุมเครือนั้นจะเกี่ยวข้องกับวิธีการใช้ข้อมูลจำเพาะ - แต่สิ่งนี้จะเกิดขึ้น

ไม่

ข้อกำหนดที่ชัดเจนของการคำนวณคือโปรแกรมคอมพิวเตอร์