ดังนั้นเมื่อฉันอยู่ที่มหาวิทยาลัยฉันได้รับการศึกษาเกี่ยวกับประโยชน์ของ UML และอนาคตของการพัฒนาโค้ด

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

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

แต่เมื่อฉันดู Visio และ Enterprise Architect ดูเหมือนว่าพวกเขาจะมีกราฟ, รูปร่าง, วัตถุคุณสมบัติหลายประเภทซึ่งส่วนใหญ่ฉันไม่ได้ใช้

ผู้คนใช้ UML เพื่อทำสิ่งที่ซับซ้อนยิ่งขึ้นเช่นการสร้างรหัสหรือการสร้างฐานข้อมูลหรือไม่?

ใช่เครื่องมือของ UML CASE เป็นหนึ่งในไอเท็มยอดนิยมของ 90s ... จากนั้นไม่สามารถส่งมอบได้

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

ข้อยกเว้นที่เป็นไปได้เพียงอย่างเดียวต่อสิ่งนี้ที่ฉันรู้จักคือแผนภาพความสัมพันธ์เอนทิตีซึ่งไม่รวมรหัสต่อหนึ่งชิ้นเท่านั้น (ตามชื่อของมันหมายถึง) ข้อมูลและความสัมพันธ์ แต่ฉันไม่เคยได้ยินความพยายามที่ประสบความสำเร็จในการใช้ไดอะแกรม UML ใด ๆ สำหรับการสร้างรหัสจริง[อัปเดต] - นั่นคือโครงกระดูกมากกว่าคลาสและรหัสเล็ก ๆ น้อย ๆ เช่น getters / setters - ยกเว้นในเครื่องมือ / วัตถุประสงค์พิเศษเช่น ORM โดย Doc Brown ด้านล่าง[/ อัปเดต]และฉันคิดว่านี่ไม่ใช่อุบัติเหตุ

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

ดังนั้นเมื่อฉันอยู่ที่ uni (ไม่นานมานี้) ฉันได้รับแจ้งว่า UML เป็นอนาคต UML จะแทนที่การเขียนโปรแกรมและเราจะสร้างโค้ดจากไดอะแกรมเป็นต้น

พวกเขาผิด ที่จะเกิดขึ้นเกี่ยวกับเวลาที่ผู้คนละทิ้งคำพูดและกลับไปทาสีถ้ำ

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

NO

ตำนานนั้นตั้งอยู่บนสมมติฐานที่ล้มเหลวในการเขียน:

class ClassName extends SomeThing
{

}

... มันยากและความต้องการของระบบอัตโนมัติ

คุณยังอาจพบผู้เชื่อเป็นครั้งคราวหรือฝูงชนของผู้ศรัทธา
แต่นั่นเป็นวิธีที่จะไปกับศาสนาและลัทธิ

เคยไปแล้วไม่พบว่ามันมีประโยชน์เกินไป

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

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

วิธีการที่ร่างกายยังคงต้องกรอกด้วยมือเพราะไดอะแกรมไม่สามารถแสดงให้เห็นว่ามีข้อยกเว้นของโครงร่างกลไกของรัฐ

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

แม้ว่าจะเป็นไปได้ที่จะสร้างรหัส (และแม้กระทั่งทั้งระบบ) โดยตรงจากโมเดล UML แต่ฉันไม่เคยพบว่ามันถูกใช้ในลักษณะนี้

จากประสบการณ์ของฉัน บริษัท ส่วนใหญ่ดูเหมือนจะใช้เป็นเครื่องมือสื่อสารสำหรับความต้องการหรือ "MS Paint สำหรับการวาดไดอะแกรม"

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

ทั้งหมดนี้ (โมเดลไดอะแกรม) มีวัตถุประสงค์เพื่อการสื่อสาร

การสร้างแบบจำลองมีประโยชน์ที่สำคัญ 4 ประการในกระบวนการพัฒนาซอฟต์แวร์:

1. เครื่องมือออกแบบรวม

2. เครื่องมือสื่อสาร

3. ช่วยในการสร้างซอฟต์แวร์

4. วิธีลดความซับซ้อนของปัญหาคำศัพท์จริง (ฉันเรียนรู้สิ่งนี้จาก @kevin cline การตอบสนองด้านบน)

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

การสร้างแบบจำลองในความคิดของฉันมีความสำคัญสำหรับการสร้างฐานข้อมูล (ER Diagrams), การทำความเข้าใจกระบวนการไหล (Activity Diagrams) และการทำความเข้าใจการโต้ตอบระหว่างผู้ใช้กับระบบ (ใช้แผนภาพกรณี)

ผู้คนใช้ UML เพื่อทำสิ่งที่ซับซ้อนยิ่งขึ้นเช่นการสร้างรหัสหรือการสร้างฐานข้อมูลหรือไม่?

ใช่แน่นอน. สามารถใช้ ERD (ไม่ใช่แผนภาพ UML) และคลาสไดอะแกรม (ขึ้นอยู่กับความสามารถของเครื่องมือของคุณ) เพื่อสร้าง:

1 - ภาษานิยามข้อมูล (DDL)

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

คุณสมบัติที่มีค่าที่สุดของเครื่องมือสร้างแบบจำลอง ได้แก่ :

1 - ความสามารถในการรักษาความสมบูรณ์ของโมเดล หากคุณทำการเปลี่ยนแปลงมันแพร่กระจายในรูปแบบ

2 - ความสามารถในการตอบคำถามที่ใช้ (ซึ่ง 'บัญชี' ที่ใช้ในแบบจำลองของฉันอยู่ที่ไหน)

3 - ความสามารถในการอนุญาตให้ผู้ใช้พร้อมกันสามารถทำงานกับแบบจำลอง

4 - ค้นหาภายในการแสดงกราฟิก

5 - การควบคุมการพิมพ์

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

7 - การสร้างรหัสฐานข้อมูลสำหรับระบบฐานข้อมูลหลายระบบ

8 - การตรวจสอบความถูกต้องของโมเดล (ตรวจสอบความสอดคล้องกุญแจที่ขาดหายไปรอบการทำงาน ฯลฯ )

ดังนั้นเครื่องมือสร้างแบบจำลองโดยเฉพาะอย่างยิ่งสิ่งที่ดีทำมากกว่า Paint

เราใช้ Software Architect ในการออกแบบระดับสูงและจัดทำเอกสารเกี่ยวกับการมีส่วนร่วมของ Arcane ในเนื้อหาของเรา บางครั้งเราสร้างโครงกระดูกของแอพจากไดอะแกรม แต่เมื่อทำเสร็จแล้วเราแยกกันทั้งคู่เราจะไม่พยายามที่จะแปลงรหัสกลับเข้าไปในไดอะแกรมหลังจากเสร็จสิ้น ฉันเคยใช้เครื่องมือที่เรียกว่า Rational XDE ซึ่งทำงานได้ดีสำหรับโปรแกรมขนาดเล็ก แต่มันจะหายไปเมื่อคุณเริ่มเพิ่มใน Swing event handler หรือพยายามทำงานกับ Struts

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

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

ในโครงการล่าสุดของฉันฉันใช้ UML-Lab (https://www.uml-lab.com) นี่เป็นเครื่องมือที่ดีที่ช่วยให้แบบจำลองวิศวกรรมย้อนกลับเช่นกัน เครื่องมือนี้สร้างโค้ด java และแม้กระทั่งคำอธิบายประกอบ JPA ซึ่งมีความแม่นยำพอสมควร

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

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

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

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

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

นอกจากนี้ตามที่กล่าวไว้ในความคิดเห็นก่อนหน้าสคีมาฐานข้อมูลสคริปต์ DDL และอื่น ๆ สามารถสร้างขึ้นได้โดยใช้โมเดล

การใช้ OAW และเครื่องมือสร้างแบบจำลองเช่น Enterprise Architect เราสามารถเขียนตัวสร้างรหัสที่แข็งแกร่งขึ้นซึ่งสามารถช่วยในการสร้างไฟล์การกำหนดค่ารหัสโรงงานโดยใช้แบบแผนและค่าที่ติดแท็ก

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

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

การแก้ปัญหาคือการแปลงเป็นแผนที่โลกแห่งความเป็นจริงและดังนั้นรหัสโครงการทั้งหมดเป็นรูปแบบ UML เดียว การมีแบบจำลองเดียวและตรรกะแบบเต็มของโครงการคุณสามารถสร้างมุมมองจากแบบจำลองไม่ใช่จากรหัสในแต่ละครั้ง มีความคิดริเริ่มที่กล้าหาญทำโดย Omondo ในเทคโนโลยี Java / Jee แนวคิดคือการทำข้อมูลให้ตรงกันสด MOF และ UML โดยตรงกับรหัสและ ORM ไดอะแกรม UML เป็นเพียงมุมมองระดับสูงของแบบจำลองที่ทำแผนที่ทั้งโครงการ คุณสามารถสร้างมุมมองหลายร้อยมุมมองเพิ่มบันทึกย่อหลายร้อยรายการ ฯลฯ .... เพื่อให้เข้าใจโครงการได้ดียิ่งขึ้น รหัสจะถูกสร้างขึ้นเฉพาะเมื่อองค์ประกอบมีการเปลี่ยนแปลงหรือสร้างขึ้น สุดยอดเทคโนโลยีที่ Java Id ถูกแมปกับ UML id โดยไม่มีบริดจ์การแปลงแบบดั้งเดิมระหว่าง MOF และ UML

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

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