ไดอะแกรม UML ใดที่ยังคงใช้กันอย่างแพร่หลาย [ปิด]

ฉันสอนวิศวกรรมซอฟต์แวร์ในระดับปริญญาตรีและฉันมีคำถามกับผู้ปฏิบัติงาน UML

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

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

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

จากไดอะแกรมที่เสนอโดย UML ไดอะแกรมคลาสและไดอะแกรมลำดับยังคงใช้กันอย่างแพร่หลายตามด้วยแผนภาพสถานะ:

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

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

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

ฉันรู้สึกว่าได้รับการยืนยันในข้อความนี้เมื่อมองในร้านหนังสือ สองสามปีที่ผ่านมาคุณสามารถหาหนังสือมากมายใน UML 2.0 ทุกวันนี้หากคุณกำลังมองหา UML 2.5 ตัวเลือกนั้นค่อนข้าง จำกัด เลวร้ายยิ่งกว่าเดิม: ผู้เขียนหลายคนไม่ได้พยายามแก้ไขหนังสือเก่าของพวกเขาเพื่อให้ทันสมัยอยู่เสมอ (ตัวอย่าง: คำนำ" UML กลั่น " ของ Fowler ที่ดีซึ่งยังคงมีอยู่ตั้งแต่ปี 2003 ด้วย UML 2.0 และองค์ประกอบของAmblerของ UML 2.0 style "!)

ฉันไม่คิดว่าแนวโน้มที่ลดลงนี้จะเปลี่ยนแปลงไปโดยมองไปที่ลักษณะทั่วไปของความคล่องตัวและการส่งเสริม "ซอฟต์แวร์การทำงานมากกว่าเอกสารที่ครอบคลุม"

ในตอนท้ายฉันขอยั่วยุมากว่าวิธีการสร้างแบบจำลองดูเหมือนจะเป็นไปตามรูปแบบของดาร์วิน: เทคนิคการสร้างไดอะแกรมที่เหมาะสมที่สุดเท่านั้นที่จะมีชีวิตรอดผู้ที่ให้ความได้เปรียบอย่างชัดเจนกับวิธีการที่ไม่เป็นทางการ ทำไมต้องวาดไดอะแกรมกิจกรรม A1 เมื่อรหัสที่เกี่ยวข้องสามารถใส่ลงในแผ่น A4 ได้?) ;-)

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

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

เครื่องมือเช่นการทำงาน UML ดีที่สุดถ้าคุณใช้เมื่อพวกเขาเพิ่มมูลค่า ; เช่น

• สำหรับโครงการขนาดใหญ่
• สำหรับส่วนที่ซับซ้อนของโครงการ
• เมื่อการออกแบบโครงการต้องการอินพุตจากหลายคน

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

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

ยังคงใช้ UML ในร่องลึก แต่เช่นเคยคนใช้ชุดย่อยของมัน เซตย่อยใดบ้างที่มีปัญหาในมือ

UML มีหลายรุ่น แต่เช่นเคยผู้คนใช้สัญลักษณ์นี้อย่างไม่เป็นทางการและไม่แน่นอน

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

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

สอนพวกเขาว่ามันโอเคที่จะถามสิ่งที่มีความหมาย อย่าสอนพวกเขาให้แก้ไขผู้อื่นที่ฝ่าฝืนกฎที่จินตนาการไว้ เราแค่พยายามสื่อสารที่นี่

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

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

แต่ฉันคิดว่าเราทุกคนรู้ว่ามีความแตกต่างระหว่างหัวลูกศรปกติและหัวลูกศรเปิด ขวา?

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