วิศวกรรมซอฟต์แวร์แบบขับเคลื่อน (MDSE) คืออะไร?

ฉันได้พบกับคำย่อ MDSE วันนี้ใน infoqและข้อมูลที่ฉันสามารถค้นหาสิ่งที่ค่อนข้างชัดเจนและคำอธิบายที่เต็มไปด้วย buzzwords:

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

และเห็นได้ชัดว่าทุกคนกำลังทำมัน: (จากบทความอีกครั้ง)

เรากำลังใกล้จะถึงยุคของ MDSE แล้ว ในอีก 5 - 10 ปีข้างหน้าเราจะเห็นการเปลี่ยนแปลงอย่างมีนัยสำคัญต่อ MDSE เท่าที่ฉันเชื่อว่าภายในสิ้นระยะเวลานี้บางที 60 - 80% ของซอฟต์แวร์จะได้รับการออกแบบโดยใช้เทคนิคแบบจำลอง

ฉันต้องการคำอธิบายที่เป็นรูปธรรมและไม่มีคำบอกเล่าเกี่ยวกับสิ่งที่ MDSE เป็นรูปธรรม มันคือการวาดกล่อง UML และสร้างรหัสด้วยเช่นที่พวกเขาทำใน 90s กับ Rational Rose?

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

"model ซอฟต์แวร์วิศวกรรมขับเคลื่อน (MDSE)" เป็นสัญญาการตลาดของผู้ผลิตเครื่องมือซอฟต์แวร์ที่ "เร็ว ๆ นี้" ส่วนสำคัญของซอฟต์แวร์สามารถสร้างขึ้นได้จากซอฟต์แวร์รุ่น

หุ้นส่วนสัมภาษณ์ใน บทความที่คุณอ้างถึง Robert Howe เป็นผู้ผลิตเครื่องมือ (ดูรายละเอียดได้ที่http://www.verum.com/ )

แต่กับผู้ผลิตเครื่องมือสัญญา mdse ยังไม่ได้กลายเป็นกระแสหลัก

ระบบ hybris ร้านอินเทอร์เน็ตเป็นตัวอย่างการทำงานของ "MDSE" คุณเป็นซอฟต์แวร์รักษา developper XML-รูปแบบไฟล์ ( "* -items.xml") และ codegenerators / ล่ามสร้าง DB-modell / java รหัสสำหรับการติดตา / GUIs ออกมาจากมัน หากคุณต้องการแอททริบิวต์เพิ่มเติมเพียงแค่เพิ่มไปยังโมเดล xml และหลังจากที่ตัวสร้าง / ล่ามทำหน้าที่ได้แล้วคุณสามารถใช้แอททริบิวเพื่อสร้างตรรกะทางธุรกิจ

IMHO "แบบจำลองการขับเคลื่อน " เป็นการพูดเกินจริงครั้งใหญ่โดยเฉพาะเมื่อใช้ร่วมกับ buzzwords เช่น "การออกแบบ" หรือ "วิศวกรรมซอฟต์แวร์" (แทนที่จะเป็น "การพัฒนา") มันอาจถูกคิดค้นโดยบางคนที่มีความเข้าใจผิดว่า "การออกแบบซอฟต์แวร์" ทำโดยการวาดรูปแบบกราฟิกส่วนใหญ่กับ UML เช่นสถาปนิกวาดภาพพิมพ์เขียวสำหรับบ้านและ "การเข้ารหัส" ก็เหมือนกับการวางอิฐสำหรับบ้าน ติดตามพิมพ์เขียว (ฉันหวังว่าฉันไม่จำเป็นต้องอธิบายที่นี่ว่าทำไมสิ่งนี้ผิดถ้าคุณมีความคิดเห็นที่แตกต่างโปรดอ่าน"Code as Design" โดย Jack Reevesก่อนที่จะลดระดับฉัน)

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

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

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

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