UML ใช้ได้จริงหรือไม่? [ปิด]

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

แก้ไข:ประสบการณ์ของฉันถูก จำกัด ไว้ที่โครงการขนาดเล็กภายใต้ 10 โครงการสำหรับนักพัฒนา

แก้ไข:คำตอบที่ดีมากมายและแม้ว่าจะไม่ใช่คำที่ละเอียดที่สุด แต่ฉันเชื่อว่าคำตอบที่เลือกนั้นสมดุลที่สุด

ในระบบที่ซับซ้อนเพียงพอมีสถานที่บางแห่งที่UMLคิดว่ามีประโยชน์

แผนภาพที่มีประโยชน์สำหรับระบบแตกต่างกันไปตามการใช้งาน
แต่สิ่งที่ใช้กันอย่างแพร่หลาย ได้แก่ :

• คลาสไดอะแกรม
• แผนภาพสถานะ
• แผนภาพกิจกรรม
• แผนภาพลำดับ

มีองค์กรหลายแห่งที่สาบานกับพวกเขาและอีกหลายแห่งที่ปฏิเสธพวกเขาโดยสิ้นเชิงเพราะเสียเวลาและความพยายามอย่างที่สุด

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

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

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

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

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

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

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

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

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

ฉันต้องไม่เห็นด้วย UML ถูกใช้ทั่วทุกที่ - ทุกที่ที่มีการออกแบบโครงการไอที UML มักจะอยู่ที่นั่น

ตอนนี้ไม่ว่าจะถูกใช้อย่างดีก็เป็นอีกเรื่องหนึ่ง

ดังที่ Stu กล่าวไว้ฉันพบว่า Use Case ทั้งสองแบบ (พร้อมกับคำอธิบายกรณีการใช้งาน) และแผนภาพกิจกรรมเป็นประโยชน์สูงสุดจากมุมมองของนักพัฒนา

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

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

ฉันจะรับรองคำตอบของฉันโดยระบุว่าฉันไม่มีประสบการณ์ในสภาพแวดล้อมการพัฒนาองค์กรขนาดใหญ่ (เหมือน IBM)

วิธีที่ฉันดู UML และRational Unified Processคือการพูดคุยเกี่ยวกับสิ่งที่คุณกำลังจะทำมากกว่าการทำในสิ่งที่คุณกำลังจะทำจริงๆ

(กล่าวอีกนัยหนึ่งคือเสียเวลามาก)

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

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

เวลาเรียนมี จำกัด เช่นเดียวกับเวลานอกห้องเรียน ด้วยเหตุนี้เราจึงต้องทำการตรวจสอบโค้ดในการประชุมชั้นเรียนทุกครั้ง แต่การที่มีนักเรียน 25 คนที่ลงทะเบียนเรียนแต่ละครั้งนั้นสั้นมาก เครื่องมือที่เราพบว่ามีค่าที่สุดในเซสชันการทบทวนเหล่านี้ ได้แก่ ERD ไดอะแกรมคลาสและไดอะแกรมลำดับ แผนภาพของ ERD และคลาสทำได้เฉพาะใน Visual Studio ดังนั้นเวลาที่ต้องใช้ในการสร้างจึงเป็นเรื่องเล็กน้อยสำหรับนักเรียน

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

หากไม่ใช้ไดอะแกรมเราจะต้องใช้เวลาไปทีละไฟล์รหัสของนักเรียนเพื่อค้นหาปัญหา

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

• การสื่อสาร
• เอกสารการออกแบบ / โซลูชันที่ได้มาตรฐาน
• นิยาม DSL (ภาษาเฉพาะโดเมน)
• นิยามโมเดล (โปรไฟล์ UML)
• รูปแบบ / การใช้สินทรัพย์
• การสร้างรหัส
• Model to Model transformations

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

การอภิปรายควรขยายขอบเขตออกไปจากวิธีที่ UML สามารถ over kill หรือนำไปใช้กับโครงการขนาดเล็กเพื่อหารือว่าเมื่อใดที่ UML เหมาะสมหรือจะปรับปรุงผลิตภัณฑ์ / โซลูชันได้จริงตามที่ควรจะใช้ UML มีสถานการณ์ที่ UML สำหรับนักพัฒนารายหนึ่งสามารถรับรู้ได้เช่นกันเช่น Pattern Application หรือ Code Generation

UML ทำงานให้ฉันมาหลายปีแล้ว เมื่อฉันเริ่มต้นฉันอ่านUML Distilledของ Fowler ซึ่งเขาบอกว่า "ทำแบบจำลอง / สถาปัตยกรรม / ฯลฯ ให้เพียงพอ" เพียงแค่ใช้สิ่งที่คุณต้องการ !

จากมุมมองของวิศวกร QA แผนภาพ UML ชี้ให้เห็นข้อบกพร่องที่อาจเกิดขึ้นในตรรกะและความคิด ทำให้งานของฉันง่ายขึ้น :)

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

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

ที่กล่าวว่าฉันชอบเครื่องมือ UML ต่อไปนี้:

1. ไวโอเล็ต - ถ้ามันง่ายกว่านั้นมันก็คือกระดาษแผ่นหนึ่ง

2. Altova UModel - เครื่องมือที่ดีสำหรับ Java และ C # Modeling

3. MagicDraw - เครื่องมือทางการค้าที่ฉันชอบสำหรับการสร้างแบบจำลอง

4. โพไซดอน - เครื่องมือที่ดีและเหมาะสำหรับคนเจ้าชู้

5. StarUML - เครื่องมือสร้างแบบจำลองโอเพ่นซอร์สที่ดีที่สุด

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

จากหัวข้อ: การใช้โมเดลภายในกระบวนการพัฒนาที่http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

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

คุณอาจต้องการอ่านคำตอบของฉันต่อโพสต์ต่อไปนี้:

เรียนรู้“ การออกแบบ / สถาปัตยกรรมซอฟต์แวร์ที่ดี” ได้อย่างไร? ที่/programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

แม้ว่าการสนทนานี้จะไม่ได้ใช้งานมานาน แต่ฉันก็มีประเด็นสำคัญสองสามประการที่ต้องเพิ่ม

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

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

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

ฉันชอบทำแผนภาพ use-case แต่ฉันไม่ได้เจอคนที่คิดว่าพวกเขามีค่ามากเกินไป

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

ฉันพบว่า UML ไม่มีประโยชน์สำหรับโครงการขนาดเล็กมาก แต่เหมาะสำหรับโครงการขนาดใหญ่

โดยพื้นฐานแล้วไม่สำคัญว่าคุณจะใช้อะไรคุณต้องคำนึงถึงสองสิ่ง:

• คุณต้องการการวางแผนสถาปัตยกรรมบางประเภท
• คุณต้องแน่ใจว่าทุกคนในทีมใช้เทคโนโลยีเดียวกันในการวางแผนโครงการ

UML ก็แค่นั้น: มาตรฐานในการวางแผนโครงการของคุณ หากคุณจ้างคนใหม่มีแนวโน้มที่จะรู้มาตรฐานที่มีอยู่ไม่ว่าจะเป็น UML, Flowchard, Nassi-Schneiderman อะไรก็ตาม - แทนที่จะเป็นของที่คุณมีอยู่ในบ้าน

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

UML มีประโยชน์ใช่แน่นอน! การใช้งานหลักที่ฉันทำคือ:

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

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

ฉันเชื่อว่าอาจมีวิธีใช้ประโยชน์จากปลา UML แบบค๊อกเบิร์นว่าวและการใช้งานระดับน้ำทะเลตามที่ฟาวเลอร์อธิบายไว้ในหนังสือ "UML Distilled" ของเขา ความคิดของฉันคือการใช้ Cockburn use case เพื่อช่วยในการอ่านโค้ด

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

โปรดตรวจสอบโพสต์หากคุณสนใจ ไปที่นี่ .

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

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

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

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

ปัญหาเกี่ยวกับ UML คือหนังสือของผู้ก่อตั้งคลุมเครือเกินไป

UML เป็นเพียงภาษาไม่ใช่วิธีการจริงๆ

สำหรับฉันฉันพบว่าการขาด UML schema สำหรับโครงการ Opensource น่ารำคาญมาก ใช้สิ่งที่คล้าย Wordpress คุณมีสคีมาฐานข้อมูลไม่มีอะไรอื่น คุณต้องเดินไปรอบ ๆ codex api เพื่อพยายามรับภาพใหญ่

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

ดูเหมือนว่า UML จะดีสำหรับโครงการขนาดใหญ่ที่มีทีมงานจำนวนมาก อย่างไรก็ตามฉันเคยทำงานในทีมเล็ก ๆ ที่การสื่อสารดีขึ้น

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

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

ความเชื่อของฉันคือการใช้ UML นั้นขึ้นอยู่กับสถานการณ์ที่ทีมพัฒนากำลังทำงานอยู่

จากประสบการณ์ของฉัน:

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

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

UML มีประโยชน์สองวิธี:

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

• ด้านการจัดการ: แผนภาพ UMl เป็นภาพสะท้อนของความต้องการของลูกค้าที่ไม่ถูกต้อง: หากคุณเขียนโค้ดโดยไม่มี UML คุณอาจพบข้อบกพร่องที่ต้องใช้หลังจากทำงานไปหลายชั่วโมง แผนภาพ UML ช่วยให้คุณสามารถค้นหาจุดที่ขัดแย้งที่เป็นไปได้และแก้ไขก่อนที่การเข้ารหัส => ช่วยวางแผนของคุณ

โดยทั่วไปโครงการทั้งหมดที่ไม่มีแผนภาพ UML จะมีการวิเคราะห์แบบผิวเผินหรือมีขนาดสั้น

ถ้าคุณอยู่ใน LinkedIn กลุ่มวิศวกรระบบดูการอภิปรายเก่าของฉัน

ในท้ายที่สุด UML มีอยู่เพราะ RUP เท่านั้น เราต้องการ UML หรือสิ่งที่เกี่ยวข้องเพื่อใช้ Java / .Net หรือไม่? คำตอบที่ใช้ได้จริงก็คือพวกเขามีเอกสารของตัวเอง (javadoc ฯลฯ ) ซึ่งเพียงพอและช่วยให้เราทำงานให้ลุล่วงได้!

UML ไม่ใช่ thanx

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

UML มีตำแหน่งในอุตสาหกรรมนี้อย่างแน่นอน ลองนึกภาพว่าคุณกำลังสร้างซอฟต์แวร์สำหรับเครื่องบิน Boing หรือระบบอื่น ๆ ที่ซับซ้อน UML และ RUP จะช่วยได้มากที่นี่

UML เป็นเพียงหนึ่งในวิธีการสื่อสารภายในผู้คน ไวท์บอร์ดดีกว่า