ทำไมเราไม่สามารถจับการออกแบบซอฟต์แวร์ให้มีประสิทธิภาพมากกว่า [ปิด]

ในฐานะวิศวกรเราทุกคน "ออกแบบ" สิ่งประดิษฐ์ (อาคารโปรแกรมวงจรโมเลกุล ... ) นั่นเป็นกิจกรรม (คำกริยาออกแบบ) ที่สร้างผลลัพธ์บางอย่าง (คำนามการออกแบบ)

ฉันคิดว่าเราทุกคนเห็นพ้องต้องกันว่าการออกแบบคำนามเป็นสิ่งที่แตกต่างจากสิ่งประดิษฐ์เอง

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

ฉันคิดว่าการออกแบบซอฟต์แวร์มีดังนี้:

• ข้อกำหนดที่ชัดเจนสำหรับซอฟต์แวร์ที่ควรทำและใช้งานได้ดีเพียงใด
• รหัสรุ่นที่ชัดเจน (ส่วนนี้เป็นเรื่องง่ายใคร ๆ ก็มี)
• คำอธิบายสำหรับวิธีการที่แต่ละส่วนของรหัสทำหน้าที่เพื่อให้บรรลุข้อกำหนด (เช่นความสัมพันธ์ระหว่างชิ้นส่วน spec และชิ้นส่วนรหัส)
• เหตุผลว่าทำไมรหัสเป็นวิธีที่มันเป็น (เช่นทำไมเป็นทางเลือกหนึ่งมากกว่าอีก)

สิ่งที่ไม่ใช่การออกแบบคือมุมมองเฉพาะของรหัส ตัวอย่างเช่น [ไม่ให้เลือกโดยเฉพาะ] แผนภาพ UML ไม่ได้ออกแบบ แต่เป็นคุณสมบัติที่คุณสามารถได้รับจากรหัสหรือคุณสมบัติที่คุณต้องการให้คุณได้มาจากรหัส แต่ตามกฎทั่วไปคุณไม่สามารถรับโค้ดจาก UML ได้

ทำไมหลังจากสร้างซอฟต์แวร์มานานกว่า 50 ปีแล้วทำไมเราไม่มีวิธีปกติในการถ่ายทอดสิ่งนี้ (อย่าลังเลที่จะโต้แย้งฉันด้วยตัวอย่างที่ชัดเจน!)

แม้ว่าเราจะทำเช่นนั้นชุมชนส่วนใหญ่ดูเหมือนจะมุ่งเน้นไปที่การรับ "รหัส" ที่คำนามการออกแบบจะหายไป (IMHO จนกว่าการออกแบบจะกลายเป็นจุดประสงค์ของวิศวกรรมด้วยสิ่งประดิษฐ์ที่สกัดจากการออกแบบเราจะไม่แก้ไขเรื่องนี้)

คุณเคยเห็นสิ่งที่เป็นวิธีการบันทึกการออกแบบ (ในแง่ที่ฉันได้อธิบายไว้)? การอ้างอิงอย่างชัดเจนไปยังเอกสารจะดี ทำไมคุณคิดว่าวิธีที่เฉพาะเจาะจงและทั่วไปไม่ประสบความสำเร็จ? เราจะเปลี่ยนแปลงสิ่งนี้ได้อย่างไร

[ฉันมีความคิดของตัวเองที่ทำให้มุมมองสัญลักษณ์แสดงหัวข้อย่อยข้างต้นมี แต่ฉันสนใจคำตอบของคนอื่น ... และมันยากที่จะใช้รูปแบบของฉัน [[และอาจเป็นปัญหาที่แท้จริง: -]]]

แก้ไข 2011/1/3: หนึ่งในคำตอบของกระทู้บอกว่า "เอกสาร" (น่าจะเป็นข้อความโดยเฉพาะอย่างยิ่งไม่เป็นทางการ) อาจจะเพียงพอ ฉันเดาว่าฉันควรชี้แจงว่าฉันไม่เชื่อสิ่งนี้ เครื่องมือของ CASE ปรากฏในฉากที่เริ่มต้นในยุค 80 แต่เครื่องมือเริ่มต้นส่วนใหญ่เพิ่งจับพิกเซลสำหรับไดอะแกรมของสิ่งที่คุณวาด ในขณะที่เครื่องมือต่าง ๆ ประสบความสำเร็จในเชิงพาณิชย์พวกเขาไม่ได้มีประโยชน์มาก ความเข้าใจที่สำคัญคือหากสิ่งประดิษฐ์เพิ่มเติม "ออกแบบ" ไม่สามารถตีความได้อย่างเป็นทางการคุณจะไม่สามารถรับความช่วยเหลือจากเครื่องมือร้ายแรง ฉันเชื่อว่าความเข้าใจแบบเดียวกันนี้ใช้กับรูปแบบการจับภาพการออกแบบที่มีประโยชน์ในระยะยาว: ถ้ามันไม่มีโครงสร้างที่เป็นทางการ เอกสารข้อความล้มเหลวในการทดสอบนี้มาก

ฉันคิดว่ามีหลายสาเหตุที่เรายังไม่ดีในเรื่องนี้

1. ผู้คนเป็นเวลานานถึงแม้ว่าซอฟต์แวร์เป็นเหมือนบ้านและกำลังใช้กระบวนการและความคิดจากการก่อสร้าง "สถาปนิกซอฟต์แวร์" เป็นชื่อที่โปรแกรมเมอร์ทุกคนต้องการ ในช่วงสิบปีที่ผ่านมาสถาปนิกซอฟต์แวร์เกือบเสียชีวิต แนวคิดของกระบวนการน้ำตกที่คุณมีสถาปนิกคนแรกบอกว่าซอฟต์แวร์ควรทำงานอย่างไรและดูอย่างไรจากนั้นให้ผู้คนสร้างไดอะแกรมว่าควรสร้างอย่างไรและในที่สุดก็มีลิงโค๊ดที่ใช้งานเวิร์กโฟลว์ / UML ที่ดีเหล่านี้ ตอนนี้เยาะเย้ยกันอย่างแพร่หลาย ดังนั้นในความเป็นจริงอุตสาหกรรมทั้งหมดกำลังเห่าเส้นทางที่ผิดเป็นเวลา 40 ปี

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

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

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

คุณอาจสนใจอ่านเอกสารตรวจสอบย้อนกลับของซอฟต์แวร์ ในลำดับใดไม่มี:

• CUBRANIC, D. , MURPHY, GC, SINGER, J. และ BOOTH KELLOGG, S. Hipikat: หน่วยความจำโครงการสำหรับการพัฒนาซอฟต์แวร์ ธุรกรรมเกี่ยวกับวิศวกรรมซอฟต์แวร์ 31, 6 (2005), 446–65
• TANG, A. , BABAR, MA, GORTON, I. , และ HAN, J. การสำรวจการใช้และเอกสารประกอบของเหตุผลการออกแบบสถาปัตยกรรม ใน Proc การประชุม IEEE / IFIP ที่ทำงานครั้งที่ 5 เกี่ยวกับสถาปัตยกรรมซอฟต์แวร์ (2005)
• RAMESH, B. , POWERS, T. , STUBBS, C. , และ EDWARDS, M. ดำเนินการตามข้อกำหนดการติดตามย้อนกลับ: กรณีศึกษา ใน Proc ของ Int'l Symp เกี่ยวกับวิศวกรรมความต้องการ (York, 1995)
• HORNER, J. , และ ATWOOD, ME เหตุผลการออกแบบ: เหตุผลและอุปสรรค ใน Proc การประชุม Nordic ครั้งที่ 4 เรื่องการปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์: การเปลี่ยนบทบาท (Oslo, Norway, 2006)
• CLELAND-HUANG, J. , SETTIMI, R. , ROMANOVA, E. , BERENBACH, B. , และ CLARK, S. แนวทางปฏิบัติที่ดีที่สุดสำหรับการตรวจสอบย้อนกลับอัตโนมัติ คอมพิวเตอร์ 40, 6 (มิถุนายน 2550), 27–35
• ASUNCION, H. , FRANÇOIS, F. , และ TAYLOR, RN เครื่องมือตรวจสอบย้อนกลับอุตสาหกรรมซอฟต์แวร์แบบครบวงจร ใน Proc การประชุมร่วมครั้งที่ 6 ของซอฟท์แวร์ Eng Conf ยุโรปและ ACM SIGSOFT Int'l Symp บนพื้นฐานของวิศวกรรมซอฟต์แวร์ (ESEC / FSE) (Dubrovnik, 2007)

โปรดทราบว่านี่เป็นเพียงส่วนเล็ก ๆ ของภูเขาน้ำแข็งและฉันแน่ใจว่าฉันได้ทิ้งเอกสารสำคัญไว้แล้ว

ในบันทึกแยกงานของฉันใน Arcum เป็นวิธีสำหรับโปรแกรมเมอร์เพื่อแสดงถึง IDE การใช้การออกแบบ crosscutting สำนวน เมื่อแสดงแล้วโปรแกรมเมอร์สามารถเปลี่ยนซอร์สโค้ดของตนเพื่อใช้การใช้งานทางเลือก:

• Macneil Shonle, William G. Griswold และ Sorin Lerner นอกเหนือจาก refactoring: กรอบสำหรับการบำรุงรักษาแบบแยกส่วนของ crosscutting สำนวนการออกแบบ ในการประชุมร่วมครั้งที่ 6 ของการประชุมวิศวกรรมซอฟต์แวร์ยุโรปและการประชุมวิชาการ ACM SIGSOFT เรื่องรากฐานของวิศวกรรมซอฟต์แวร์ (ESEC-FSE '07; 07-07 กันยายน 2007) 175-184

บังเอิญ Arcum ยังเกี่ยวข้องกับงาน DMS ของคุณ

UML คือรายการสิ่งที่เป็นแผนสำหรับสิ่งปลูกสร้างในมุมมองของฉัน แผนเพียงอย่างเดียวไม่ได้เป็นการออกแบบนอกหลักสูตรคุณต้องการข้อมูลจำเพาะของวัสดุ (ใช้เครื่องมือรหัส) สำหรับมุมมองทั่วไปของอาคาร (การแสดงแผนผังของซอฟต์แวร์ทั้งหมดรวมถึงการออกแบบ GUI) วิธีการปลูกอาคารในสภาพแวดล้อม (รูปแบบที่ชัดเจนของวิธีการที่ซอฟต์แวร์โต้ตอบกับผู้อื่น / ถูกฝังอยู่ในระบบปฏิบัติการ), มันมีผลต่อสภาพอากาศและดิน (การมีปฏิสัมพันธ์กับฮาร์ดแวร์), ... หนังสือมากมายเกี่ยวกับการออกแบบพยายามที่จะกำหนด แต่เช่นเดียวกับ มีหลายสิ่งในวิทยาศาสตร์นักวิทยาศาสตร์ทุกคนมีคำจำกัดความของตัวเองเล็กน้อย

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

ในแง่ที่ฉันพบบทความต่อไปนี้น่าสนใจ (ฉันพบมันในบริบทที่แตกต่างกันเมื่อฉันกำลังมองหาซอฟต์แวร์กราฟ แต่กระนั้น ... ) วิธีกราฟเพื่ออธิบายการออกแบบนั้นสมเหตุสมผลสำหรับฉันแม้ว่า - อีกครั้ง - นี่เป็นเพียงส่วนหนึ่งของการออกแบบในความคิดของฉัน สิ่งที่น่าสนใจคือวิธีการนี้ให้กรอบในการทำความเข้าใจและออกแบบการสร้างใหม่ (ต่างจาก refactor ซอฟต์แวร์) ดังที่ระบุในเอกสารต่อไปนี้:

• Wermelinger และ Fiadeiro

• Tsantalis และคณะ

มีจำนวนมากทั้งจากวิธีการอื่น ๆ เพื่ออธิบาย (ส่วนหนึ่งของ) การออกแบบเช่นเดียวกับที่มีการออกแบบโครงสร้าง (แผนภูมิ HIPO)หรือการออกแบบโปรแกรมแบบบูรณาการ , รูปแบบการออกแบบ , ...

ถึงกระนั้นตราบใดที่ยังไม่มีมาตรฐานอุตสาหกรรมก็ไม่น่าเป็นไปได้ที่จะ "แสดง" วิธีปกติ แม้หลังจาก 50+ ปี และซื่อสัตย์ถ้า บริษัท ของคุณพบวิธีที่ดีในการแสดงการออกแบบคุณจะแบ่งปันกับคนทั่วโลกหรือไม่?

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

ทุกคนในทีมของฉันมีปริญญาวิศวกรรม ... ส่วนใหญ่ EE หรือ CE วิศวกรรมสอนการออกแบบให้คุณเป็นส่วนหนึ่งของหลักสูตร

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

ฉันเห็นปัญหาสองอย่าง

ประการแรกคือมันเป็นเรื่องยากที่จะเก็บรหัสและเอกสารข้อมูลให้ตรงกัน หากแยกออกจากกันพวกเขาจะแยกออกจากกันและเอกสารจะไม่มีประโยชน์ โปรแกรมเมอร์ได้พยายามที่จะใช้เครื่องมือเพื่อทำงานในการซิงค์ (เช่น CASE-tools) แต่เครื่องมือเหล่านี้มีอยู่ระหว่างโปรแกรมเมอร์และรหัสของพวกเขาซึ่งสร้างความเสียหายได้ดีกว่า หนึ่งในข้อมูลเชิงลึกที่สำคัญของการออกแบบที่ขับเคลื่อนด้วยโดเมน (Evans, 2004) คือการออกแบบที่ดีนั้นยากมากดังนั้นเพื่อที่จะนำบางสิ่งออกมาคุณต้อง:

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

ปัญหาใหญ่อีกข้อหนึ่งที่เราออกแบบคือวิธีการออกแบบของเรานั้นไม่เพียงพอทางคณิตศาสตร์ abstractions ที่น่าสงสัยไม่ได้ให้ข้อสรุปที่ชัดเจนจากพวกเขาและโลกของตรรกะที่ใช้อย่างเคร่งครัดและความจริงที่ชัดเจนเรียกว่าคณิตศาสตร์ซึ่งโปรแกรมเมอร์ส่วนใหญ่อายห่างจาก

เครื่องมือทางคณิตศาสตร์ไม่กี่อย่างที่เรามีเช่นวิธีที่เป็นทางการนั้นเป็นสิ่งที่เทอะทะมาก

Map-ลดเป็นตัวอย่างที่ดีของคณิตศาสตร์ในการเขียนโปรแกรม แนวคิดหลักคือ: เมื่อคุณมีการเชื่อมโยงการดำเนินการแบบไบนารีคุณสามารถกระจายการดำเนินการได้อย่างง่ายดายมาก การดำเนินการแบบไบนารีคือฟังก์ชั่นที่มีพารามิเตอร์สองตัวความเชื่อมโยงหมายความว่า (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 คือ

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) โดยที่ As, Bs และ Cs สามารถเพิ่มเล็กน้อยในตำแหน่งที่ตั้งต่าง ๆ ผลลัพธ์ของพวกเขาจะถูกรวบรวม และสรุปได้ในเวลาไม่นาน

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

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

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