ไดอะแกรม UML สำคัญอย่างไรสำหรับโครงการที่ประสบความสำเร็จ [ปิด]

ฉันอยู่ในช่วงกลางของโครงการและฉันถูกขอให้เขียนไดอะแกรม UML (กรณีใช้, แผนภาพคลาส, ฯลฯ ) โครงการไม่ซับซ้อนมาก

ฉันสงสัยว่านี่จะเสียเวลาของฉันหรือไม่ ฉันควรจะทำเรื่องสนุก ๆ อย่างการเขียนโค้ดหรือไม่? และเมื่อไหร่ที่จะไม่สร้างบางอย่างโดยไม่ต้องผ่านขั้นตอนแนวคิดทั้งหมด มันคือทั้งหมดที่เกี่ยวกับความซับซ้อน? และถ้าเป็นเช่นนั้นจะวัดได้อย่างไร?

ฉันเป็นแฟนตัวยงของ UML เมื่อไม่นานมานี้ ฉันยังได้รับการรับรองจาก OMG ฉันใช้มันอย่างกว้างขวางในโครงการองค์กรขนาดใหญ่ที่ฉันเกี่ยวข้อง

วันนี้ฉันหยุด UML เกือบทั้งหมด บางครั้งฉันใช้ไดอะแกรมลำดับที่ฉันพบว่ามีประโยชน์มากในการอธิบายการโต้ตอบระหว่างระบบ แต่ไม่มีไดอะแกรมอื่น ๆ

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

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

การวางแผนมีความสำคัญ แต่ในฐานะนักยุทธศาสตร์ชื่อดังCarl von Clausewitzเตือน

ไม่มีแผนรณรงค์รอดชีวิตจากการสัมผัสกับศัตรูเป็นครั้งแรก

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

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

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

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

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

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

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

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

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

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

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

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

ฉันเคยทำงานในสถานที่ที่ฉันต้องการจัดการทีมนักพัฒนาสัญญาในต่างประเทศ

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

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

ข้อแม้หนึ่ง - พวกเขาทำบางครั้งต้องการที่จะสร้างสรรค์และเบี่ยงเบนจากแบบจำลองของฉัน แต่ในกรณีเหล่านั้นพวกเขาถูกต้องจริงและ UML ทั้งหมดปรับปรุงคุณภาพของผลิตภัณฑ์ขั้นสุดท้าย

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

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

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

มีจุดที่ดีที่ทำที่นี่โดยragu.pattabiแยกแยะระหว่าง UML สองชนิด ...

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

เมื่อถูกมองว่าเป็น UML ทักษะ 'ต้องมี' (10 ปีที่แล้วหรือมากกว่า) ฉันอาจจะขัดกับมันเนื่องจากมุมมองความเห็นของแฟน ๆ หลายคนในเวลา แต่ตอนนี้มันหลุดพ้นไปจากความโปรดปรานฉันพบว่าตัวเองเห็นว่ามันคืออะไร - เป็นเครื่องมือที่มีประโยชน์ที่มีข้อดี แต่ไม่ได้เป็นสัญลักษณ์ของการพัฒนาซอฟต์แวร์

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

เหตุผลเดียวที่ทำเอกสารรหัสทั้งหมดของฉันใน UML จะเป็นสัญญาที่ลูกค้าต้องการ ตัวอย่างเช่นเมื่อเขาต้องการที่จะมีตัวเลือกในการเปลี่ยนร้านค้าซอฟต์แวร์หลังจากส่วนหนึ่งของซอฟต์แวร์เสร็จสิ้น

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

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

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

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

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

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

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

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

UML มีชื่อที่ไม่ดีเนื่องจากมี IDE ที่น่ากลัวจำนวนมากทำให้สามารถสร้างต้นแบบการปัดเศษการจัดการกราฟการคลิกที่เข้มข้นและความยากลำบากในการเปลี่ยนแปลงอะไรก็ตาม UML 2.0 อาจซับซ้อนพอที่จะทำให้นักวิชาการบางคนพอใจ แต่ meta-model ดูเหมือนจะไม่ดึงดูดการใช้งานจริง

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

UML ยอดเยี่ยมมากในการรับมุมมองกราฟิกของสถาปัตยกรรมของคุณโดยใช้คลาสไดอะแกรม การโต้ตอบโดยใช้แผนภาพลำดับเป็นสิ่งมหัศจรรย์สำหรับฉัน ปัญหาไม่ใช่ UML แต่เป็น MDD สำหรับฉัน

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

ฉันพบว่าพวกเขาพูดเกินจริงอย่างมาก ฉันคิดว่าพวกเขาเป็นเพียงภาพเดียวที่ไม่ได้เขียนคำพันคำ

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

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

ฉันไม่เคยเป็นแฟนของ UML มาก่อน แต่ฉันก็เห็นคุณค่าของแผนภาพลำดับที่ดีเพื่ออธิบายการมีปฏิสัมพันธ์ระหว่างระบบหรืองานต่างๆ

อย่างไรก็ตามแผนภาพคลาสนั้นล้าสมัยก่อนที่จะเกิด การออกแบบคร่าวๆไม่จำเป็นต้องใช้ UML และเอกสารอย่างละเอียดจะถูกแยกโดยอัตโนมัติ (สด) จากฐานรหัส Javadoc และ Doxygen ได้ล้าสมัยอย่างสมบูรณ์ถึงความต้องการไดอะแกรมระดับด้วยตนเอง

สิ่งที่เกี่ยวกับเอกสารคือมีสองระดับ:

• การตัดสินใจระดับสูง (สถาปัตยกรรม) ควรเป็นเอกสารด้วยตนเอง
• ข้อเท็จจริงระดับต่ำ (ความสัมพันธ์เอนทิตี) ควรถูกแยกโดยอัตโนมัติ

ฉันมักจะทำซ้ำระหว่างรหัสและไดอะแกรม UML ฉันพบว่าไดอะแกรมช่วยในการแสดงภาพรวมและเส้นทางที่มั่นคงไปข้างหน้าและพวกเขาสามารถเปลี่ยนแปลงได้ค่อนข้างเร็วเมื่อพบปัญหา นอกจากนี้เมื่อฉันมีไดอะแกรมการเข้ารหัสมีแนวโน้มที่จะเล็กน้อย

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

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

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

ดังนั้นคำตอบสำหรับคำถามของคุณคือ "ขึ้นอยู่กับ" ในกรณีนี้ขึ้นอยู่กับผู้คนความซับซ้อนของโครงการและความสำคัญของระบบที่ทำงานอย่างถูกต้อง

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

ฉันรักไดอะแกรม แต่ถ้าฉันถูกขอให้สร้างหนึ่ง (โดยเฉพาะ UML!) ฉันจะถามคำถามสองข้อ:

1. สำหรับใคร
2. พวกเขาต้องการมันตอนนี้หรือไม่

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

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

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

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

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

ไม่ทราบว่าคำถามนั้นเกี่ยวกับข้อดีของ UML หรือเกี่ยวกับข้อดีของการออกแบบสถาปัตยกรรมของโปรแกรม

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

เกี่ยวกับการออกแบบโปรแกรม

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

2. การออกแบบจะช่วยคุณประหยัดเวลาโดยใช้รูปแบบที่รู้จักสำหรับปัญหาที่เกิดขึ้นซ้ำ ๆ

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