เหตุใด UML จึงไม่ถูกใช้ในซอฟต์แวร์ฟรีส่วนใหญ่ (เช่นบน Linux)


29

ฉันพยายามที่จะเข้าใจว่าทำไมUMLไม่ได้ถูกใช้ในส่วนซอฟต์แวร์ฟรีโครงการ ตัวอย่างเช่นระบบ Debian / Linux ของฉันอาจมีแพ็คเกจซอฟต์แวร์ฟรีมากกว่าหมื่นชุดและฉันไม่สามารถตั้งชื่อชุดที่พัฒนาโดยใช้กรอบและวิธีการ UML ที่ชัดเจนได้ ยกตัวอย่างเช่นQt , GCC , ลินุกซ์เคอร์เนล , ทุบตี , GNU แต่งหน้า , Ocaml , คำพังเพย , พร้อมเพรียง , lighttpd , libonion , นักเทียบท่าเป็นโครงการซอฟแวร์ฟรีที่ (AFAIK) ไม่ได้กล่าวถึง UML ที่ทั้งหมด

(ฉันเดาว่า UML เหมาะมากสำหรับการรับช่วงการพัฒนาอย่างเป็นทางการและไม่ใช่การพัฒนาซอฟต์แวร์ฟรี)

สังเกตว่าในขณะที่ฉันอ่านเนื้อหาเกี่ยวกับ UML ฉันไม่ได้อ้างว่ามีความเข้าใจที่ดี

ที่จริงแล้วฉันไม่สามารถตั้งชื่อซอฟต์แวร์ฟรีที่ใช้ UML ได้อย่างง่ายดาย (ยกเว้นเครื่องมือ UML บางตัวที่ใช้เป็นซอฟต์แวร์ฟรี) บางทีopenstackเป็นข้อยกเว้น (มีบางสิ่งที่กล่าวถึง UML)

(แม้แต่โครงการซอฟต์แวร์เก่าฟรีอาจใช้ UML หลังจากเริ่มต้นแล้ว แต่ไม่ได้ใช้)


เพื่อนร่วมงานบางคนที่ทำงานเกี่ยวกับพาไพรัสกล่าวว่าโครงการซอฟต์แวร์ฟรีส่วนใหญ่ไม่ได้มีรูปแบบที่เป็นทางการอย่างชัดเจน (และลึกพอ) อย่างชัดเจน นอกจากนี้ UML ยังมีความเกี่ยวข้องกับ Java มากกว่าที่อ้างไว้ (ฉันไม่แน่ใจทั้งหมดว่าจะเหมาะสมกับ Ocaml หรือ Common Lisp หรือ Haskell หรือ Javascript และอาจไม่ใช่แม้แต่ C ++ 11 .... ) บางทีการพัฒนาซอฟต์แวร์แบบว่องไวอาจไม่ง่ายนัก

ดูคำตอบนี้สำหรับคำถามที่เกี่ยวข้องอย่างใด บล็อกของ M.Fowler Is Design Dead? มีไหวพริบ

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

NB: ฉันไม่ใช่แฟน UML ด้วยตัวเอง ฉันไม่ได้กำหนด UML เป็นเอกสารกระดาษเท่านั้น แต่ยังเป็นรูปแบบข้อมูล [meta-] สำหรับเครื่องมือซอฟต์แวร์


30
อาจทำให้ UML เป็นอึ หรือเป็นเพราะซอฟต์แวร์ฟรีส่วนใหญ่ขาดเอกสารที่ดี?
BЈовић

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

18
สำหรับบางโครงการที่คุณระบุไว้เหตุผลค่อนข้างชัดเจน: เนื่องจากการเดินทางข้ามเวลายังไม่ได้ถูกคิดค้น UML ได้มาตรฐานครั้งแรกในปี 1997 โครงการ GNU มาจากปี 1983, GCC 1987, Bash 1988, GNU ทำปี 1989, Qt 1991, OCaml 196, Gnome 1997 มีเพียง lighttpd และ Unison ที่ยังอายุน้อยพอที่จะพัฒนาโดยใช้ UML แต่ lighttpd ถูกเขียนใน C และ Unison ใน OCaml ซึ่งทั้งสองเป็นภาษาที่ไม่สามารถอธิบายได้ดีใน UML นอกจากนี้นักพัฒนาซอฟต์แวร์ฟรีโดยทั่วไปเชื่อในการเขียนโค้ดในลักษณะที่สามารถเข้าใจได้โดยไม่ต้องใช้เครื่องมือภายนอก
Jörg W Mittag

26
UML ไม่ได้ใช้งานมากนักในการพัฒนาซอฟต์แวร์โอเพนซอร์ซหรือโอเพ่นซอร์ส ส่วนใหญ่จะใช้โดยคนที่พูดคุยเกี่ยวกับการพัฒนาซอฟต์แวร์
Karl Bielefeldt

16
เหตุผลเดียวกับที่ UML ไม่ได้ใช้มากในการพัฒนาซอฟต์แวร์ที่ไม่ใช่แบบฟรี ฟังดูดีบนกระดาษ แต่ในทางปฏิบัติดูเหมือนจะไม่ให้ผลประโยชน์ที่แท้จริง
JohnB

คำตอบ:


37

มีวิธีการใช้ UML ที่แตกต่างกัน ฟาวเลอร์มาร์ตินเรียกโหมดเหล่านี้ UMLและระบุที่สี่: UML เป็นหมายเหตุ , UML เป็น Sketch , UML เป็นพิมพ์เขียวและUML เป็นภาษาเขียนโปรแกรม

UML ในฐานะภาษาโปรแกรมไม่เคยถอดออกจริงๆ มีงานบางส่วนในส่วนนี้ภายใต้ชื่อที่แตกต่างกันเช่นModel Driven Architectureหรือ Model Based Software Engineering ในวิธีการนี้คุณจะสร้างแบบจำลองที่มีรายละเอียดสูงของระบบซอฟต์แวร์ของคุณและสร้างรหัสจากแบบจำลองเหล่านั้น อาจมีกรณีการใช้งานบางอย่างที่วิธีการนี้มีประโยชน์ แต่ไม่ใช่สำหรับซอฟต์แวร์ทั่วไปและโดยเฉพาะอย่างยิ่งไม่ใช่นอก บริษัท ขนาดใหญ่ที่สามารถซื้อเครื่องมือที่ให้ความสำคัญกับวิธีการนี้ เป็นกระบวนการที่ใช้เวลานาน - ฉันสามารถพิมพ์รหัสสำหรับชั้นเรียนได้เร็วกว่าที่ฉันสามารถสร้างแบบจำลองกราฟิกทั้งหมดที่จำเป็นในการใช้งาน

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

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

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


อีกด้านหนึ่งคือวัฒนธรรมโอเพ่นซอร์ส

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

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

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


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

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

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


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

6
@Euphoric ถึงแม้ว่าย่อหน้าสุดท้ายจะตอบคำถาม แต่ส่วนที่เหลือของมันจำเป็นต้องกำหนดพื้นหลังและทำให้เป็นมาตรฐานตามข้อกำหนดและแนวคิด และไม่มันมีการโหวตอีก 4 ครั้ง - ฉันเลือกที่ 5 แล้วตอบ
โธมัสโอเวนส์

3
+1 คำตอบที่ครอบคลุมมาก ในความคิดของฉันวรรคก่อนหน้านี้อธิบายถึงข้อสรุป ทำได้ดี!
Andres F.

8

ให้ใช้ Linux เป็นตัวอย่าง

  • ไม่ใช่โครงการ Object Oriented บางส่วนเช่น VFS สามารถสร้างแบบจำลองใน UML แต่คนอื่นไม่สามารถหรือไม่มีประสิทธิภาพมากเช่นโดยทั่วไปเพียงแค่การแปลตรงจากstructในแผนภาพคลาสที่ไม่มีความสัมพันธ์
  • UML นั้นดีสำหรับเอกสารเพื่อนำสิ่งใหม่มาสู่โครงการได้เร็วขึ้น นั่นไม่ใช่สิ่งที่ Linux รองรับโดยจริง ๆ ผู้คนคาดหวังที่จะเรียนรู้ด้วยตัวเอง
  • ไม่แน่ใจว่าเครื่องมือ UML ที่จะใช้คนต้องเห็นด้วยกับบางสิ่งถ้ามันจะได้รับการรักษา มีแอปพลิเคชัน java ฟรีสำหรับสิ่งนั้น แต่ฉันไม่คิดว่าหลายคนต้องการใช้มัน
  • ในยุค 90 GUI ยังคงเป็นสิ่งที่ท้าทายบน Linux เพียงไปขุดที่เก็บรายการจดหมายฉันคิดว่าคุณจะไม่พบกราฟิกใด ๆ นอกจากโลโก้สำหรับ Linux เองในรูปแบบ xpm ที่จะแสดงในเวลาบูตเครื่อง ข้อความล้วนเป็นรูปแบบที่ต้องการ
  • ฉันไม่คิดว่าจะไม่มีใครสนใจการออกแบบจริงๆ ผู้คนใส่ใจคุณลักษณะและหากพวกเขาได้รับการยอมรับรหัสจะถูกตรวจสอบ การใช้เคสยังคงอธิบายได้ดีที่สุดในคำพูดเช่นเดียวกับวิธีเขียนมาตรฐาน POSIX และ SUS
  • วัตถุจำนวนมากในโดเมนของระบบปฏิบัติการมีความเข้าใจและเป็นมาตรฐานภายในชุมชน เช่นคนจะรู้ว่าstruct in_addrรูปลักษณ์ในหน่วยความจำไม่มีไดอะแกรมใดที่สามารถทำให้ชัดเจนขึ้น
  • UML ไม่ได้ช่วยอะไรมากในอัลกอริทึมการสร้างแบบจำลองเช่นตัวจัดสรรหน่วยความจำตัวจัดกำหนดการตัวจัดการขัดจังหวะ ฯลฯ แหล่งที่มาอาจจะเข้าใจง่ายขึ้น

นี่คือสิ่งที่ฉันนึกได้ในการตั้งค่าโปรเจ็กต์ Linux ฉันคิดว่ามันเกี่ยวกับการปฏิบัติจริงมากขึ้น อยากรู้อยากเห็นฉันจำไม่ได้ว่า Tanenbaum ใช้ UML ใด ๆ ในตำราเรียนระบบปฏิบัติการของเขาในการอธิบายมินิกซ์

น่าจะพูดถึงได้ว่าฉันไม่ได้ใช้ UML ในที่ทำงาน อาจเป็น 20% ของคนที่ฉันทำงานด้วยรู้บางส่วนของ UML


4
ลินุกซ์ไม่ใช้การวางแนวทางวัตถุมันก็ไม่ได้ใช้เชิงวัตถุภาษา True, linux ยังมีส่วนที่เขียนในรูปแบบขั้นตอนมาก แต่ส่วนอื่น ๆ เช่นอินเทอร์เฟซโมดูลเคอร์เนลจะมุ่งเน้นวัตถุอย่างแน่นอน
cmaster

มีแผนภาพคลาสมากกว่าใน UML
Michael Dorner

โครงการซอฟต์แวร์ขนาดใหญ่ทุกโครงการต้องมีการออกแบบเชิงวัตถุ
Kais

ผู้มีส่วนร่วมจำเป็นต้องเข้าใจภาษาการสร้างแบบจำลองมาตรฐานก่อนที่จะทำงานในโครงการและนั่นคือสิ่งที่แสดงให้เห็นถึงความต้องการของเอกสารประกอบการสร้างแบบจำลองซอฟต์แวร์ไม่ว่าจะเป็น UML, SysML, IDEF0, ODL หรือ OCL
Kais

2

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

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

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

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

ความประทับใจใน UML ของฉันคือสิ่งที่มันพยายามทำ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.