เหตุใดจึงไม่เหมาะสมที่จะใช้ไดอะแกรม UML เพื่อวางแผนว่าจะจัดระเบียบรหัสของคุณอย่างไร

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

_{การพัฒนาซอฟต์แวร์แบบว่องไว: หลักการรูปแบบและการปฏิบัติ - Robert C. Martin}

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

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

— q126y
แหล่งที่มา

ประเด็นของลุงบ็อบก็คือสถาปัตยกรรมที่เกิดจากการพัฒนาทดสอบขับเคลื่อนอาจแตกต่างอย่างสิ้นเชิงจากแผนภาพ UML

— Robert Harvey

อ่านยังออกแบบตาย? โดย Martin fowler สำหรับการสนทนาที่สมดุลของหัวข้อนี้และการเคลื่อนไหวที่คล่องตัว

— Eliezer Steinbock

การถอนคำถามนี้เพื่อตอบสนองต่อการตัดสินที่ไม่ดีในส่วนของ @RobertHarvey และในการลงคะแนนเพื่อปิดคำถามที่สำคัญและมีประโยชน์

— David Arno

@DavidArno หากคุณมีความคิดเห็นที่ดีเกี่ยวกับสิ่งที่ควรหรือไม่ควรปิดฉันขอแนะนำให้คุณมีส่วนร่วมในการอภิปรายในเว็บไซต์เมตาของเรา ทุกคนที่โพสต์ที่นั่น (รวมถึงฉัน) อาจตกอยู่ภายใต้ "@RobertHarvey et al" ยกเว้นพนักงาน SE ไม่กี่คนและเรากังวลว่ามีมุมมองอื่นที่ไม่ได้เป็นตัวแทน แต่จนถึงขณะนี้ยังไม่มีใครปรากฏตัวเพื่อเป็นตัวแทน .

— Ixrec

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

— David Arno

คำตอบ:

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

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

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

เช่นเดียวกับสถาปนิกอาจสร้างภาพร่างเบื้องต้นเพื่อช่วยให้เธอและทีมของเธอเห็นภาพการออกแบบโดยรวมดังนั้นนักพัฒนาอาจใช้ UML หรือเครื่องมืออื่น ๆ เพื่อช่วยให้เห็นภาพการออกแบบที่ต้องการ เช่นเดียวกับภาพร่างเหล่านั้นที่ไม่ได้ติดตามอย่างสุ่มสี่สุ่มห้าดังนั้น UML จึงไม่ควรถูกสุ่มสี่สุ่มห้า การออกแบบรหัสควรพัฒนาจากการทำซ้ำแบบว่องไวและการใช้ TDD LIkewise ในฐานะสถาปนิกอาจสร้างแบบจำลองของบ้านเพื่อช่วยให้เธอและทีมงานของเธอเห็นภาพวาดดังนั้น UML สามารถใช้เพื่อช่วยให้เห็นภาพโครงสร้างของโค้ด

ตามที่ลุงบ็อบกล่าวว่าคุณไม่สามารถตรวจสอบ UML ได้คุณสามารถตรวจสอบรหัสได้เท่านั้น ดังนั้นรหัสจึงเป็นเอกสารการออกแบบที่สำคัญและถ้ามีการใช้ UML จะเป็นเอกสารประกอบรองเท่านั้น

— เดวิดอาร์โน
แหล่งที่มา

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

— Jaydee

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

— Doc Brown

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

รหัส C ธรรมดา (เช่นรหัสที่มาของลินุกซ์) อาจจะไม่ตรงกับรูปแบบโดย UML

รหัส Ocaml (พร้อมโมดูลและฟังก์ชั่น) หรือแม้แต่รหัส C ++ 11 (ที่มี lambdas และแม่แบบ) อาจไม่เหมาะกับ UML

การเขียนโปรแกรมหลายขั้นตอนและ MetaOcaml อาจไม่เหมาะกับ UML

โค้ดโปรล็อกหรือโค้ด Lisp ทั่วไปอาจไม่ตรงกับ UML

ดูเพิ่มเติมนี้คำตอบและนี้คำถามของฉัน

อ่านPragmatics ภาษาการเขียนโปรแกรมของ Scott และแนวคิด, เทคนิคและแบบจำลองของหนังสือการเขียนโปรแกรมคอมพิวเตอร์จากนั้นถามตัวเองว่าโมเดลการเขียนโปรแกรมทุกรูปแบบนั้นเหมาะสมกับ UML หรือไม่

ดูเพิ่มเติม Martin Fowler's Is Design Dead? บล็อก

— Basile Starynkevitch
แหล่งที่มา