วิศวกรรมรอบการเดินทาง ( RTE ) ในบริบทของสถาปัตยกรรมที่ขับเคลื่อนด้วยแบบจำลองคือฟังก์ชันการทำงานของเครื่องมือพัฒนาซอฟต์แวร์ที่ซิงโครไนซ์สิ่งประดิษฐ์ซอฟต์แวร์ที่เกี่ยวข้องสองรายการขึ้นไป เช่น ซอร์สโค้ด โมเดลไฟล์การกำหนดค่า เอกสาร ฯลฯ ระหว่างกัน^{[ 1 ]}ความจำเป็นของวิศวกรรมรอบการเดินทางเกิดขึ้นเมื่อมีข้อมูลเดียวกันอยู่ในสิ่งประดิษฐ์หลายรายการ และเมื่ออาจเกิดความไม่สอดคล้องกันในกรณีที่สิ่งประดิษฐ์บางรายการได้รับการอัปเดต ตัวอย่างเช่น ข้อมูลบางส่วนถูกเพิ่ม/เปลี่ยนแปลงในสิ่งประดิษฐ์เพียงรายการเดียว (ซอร์สโค้ด) และส่งผลให้ข้อมูลนั้นหายไป/ไม่สอดคล้องกับสิ่งประดิษฐ์อื่นๆ (ในโมเดล)

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

หนังสือหลายเล่มอธิบาย RTE สองประเภท: ^{[ 2 ] : 459}

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

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

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

เครื่องมือเชิงพาณิชย์และต้นแบบการวิจัยจำนวนมากสนับสนุน RTE รูปแบบนี้ หนังสือปี 2007 ระบุว่าRational Rose , Together , ESS-Model , BlueJและFujabaเป็นหนึ่งในเครื่องมือที่สามารถทำได้ โดย Fujaba กล่าวกันว่าสามารถระบุรูปแบบการออกแบบ ได้ ด้วย^{[ 3 ]}

ตัวอย่างเช่น หนังสือปี 2005 เกี่ยวกับVisual Studioระบุว่าปัญหาทั่วไปในเครื่องมือ RTE คือโมเดลที่กลับด้านจะไม่เหมือนกับโมเดลเดิม เว้นแต่เครื่องมือจะได้รับความช่วยเหลือจากการใส่คำอธิบายประกอบที่ยุ่งยากในซอร์สโค้ด^{[ 4 ]}ส่วนพฤติกรรมของ UML ก่อให้เกิดความท้าทายมากยิ่งขึ้นสำหรับ RTE

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

รูปแบบที่จัดการได้ง่ายกว่าของวิศวกรรมการเดินทางไปกลับ (Round-trip Engineering: RTE) ถูกนำมาใช้ในบริบทของอินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน (API) ของเฟรมเวิร์ก โดยที่แบบจำลองที่อธิบายการใช้งาน API ของเฟรมเวิร์กโดยแอปพลิเคชันจะถูกซิงโครไนซ์กับโค้ดของแอปพลิเคชันนั้น ในการตั้งค่านี้ API จะกำหนดวิธีที่ถูกต้องทั้งหมดที่สามารถใช้เฟรมเวิร์กในแอปพลิเคชันได้ ซึ่งช่วยให้สามารถตรวจจับการใช้งาน API ในโค้ดได้อย่างแม่นยำและครบถ้วน รวมถึงการสร้างโค้ดที่มีประโยชน์ซึ่งนำการใช้งาน API ที่ถูกต้องมาใช้ ตัวอย่างการใช้งาน RTE ที่โดดเด่นสองแบบในหมวดหมู่นี้ ได้แก่ภาษาสร้างแบบจำลองเฉพาะเฟรมเวิร์กและSpring Roo (Java)

การออกแบบแบบไป-กลับ (Round-trip engineering หรือ RTE) มีความสำคัญอย่างยิ่งต่อการรักษาความสอดคล้องระหว่างโมเดลหลายๆ โมเดล และระหว่างโมเดลกับโค้ดในสถาปัตยกรรมแบบขับเคลื่อนด้วยโมเดล (Model-driven architectureหรือ MDA) ของObject Management Group (OMG) OMG ได้เสนอ มาตรฐาน QVT (query/view/transformation) เพื่อจัดการกับการแปลงโมเดลที่จำเป็นสำหรับ MDA จนถึงปัจจุบัน มีการสร้างการใช้งานตามมาตรฐานนี้เพียงไม่กี่แห่ง (จำเป็นต้องนำเสนอประสบการณ์จริงเกี่ยวกับการใช้งาน MDA ในส่วนที่เกี่ยวข้องกับ RTE)

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

ข้อกำหนดไดอะแกรม UML (หากใช้สำหรับ MDA) ถูกวิพากษ์วิจารณ์ว่าขาดรายละเอียดที่จำเป็นในการมีข้อมูลเดียวกันกับที่ครอบคลุมอยู่ในซอร์สโค้ดของโปรแกรม นักพัฒนาบางคนถึงกับอ้างว่า "โค้ดคือการออกแบบ" ^{[ 5 ] [ 6 ]}

มีความเสี่ยงอย่างร้ายแรงที่รหัสที่สร้างขึ้นจะแตกต่างจากแบบจำลองอย่างรวดเร็ว หรือแบบจำลองที่วิศวกรรมย้อนกลับจะสูญเสียการสะท้อนบนรหัส หรือปัญหาทั้งสองนี้ผสมกันอันเป็นผลมาจากความพยายามในการวิศวกรรมซ้ำเป็นรอบ^{[ 7 ]}

ในส่วนของพฤติกรรม/ไดนามิกของUMLสำหรับคุณสมบัติเช่นแผนภาพสถานะไม่มีสิ่งที่เทียบเท่าในภาษาโปรแกรม การแปลในระหว่างการสร้างโค้ดจะส่งผลให้คำสั่งการเขียนโปรแกรมทั่วไป (เช่นif,switch,enum) หายไปหรือถูกตีความผิด หากแก้ไขและนำเข้ากลับอาจส่งผลให้โมเดลแตกต่างหรือไม่สมบูรณ์^{[ 8 ] [ 9 ]}เช่นเดียวกันกับโค้ดสั้นที่ใช้ในขั้นตอนการสร้างโค้ดสำหรับการใช้งานรูปแบบและตรรกะเฉพาะของผู้ใช้: เมื่อผสมกันแล้วอาจไม่สามารถวิศวกรรมย้อนกลับได้ง่าย^{[ 8 ] [ 9 ]}

นอกจากนี้ ยังขาดเครื่องมือขั้นสูงสำหรับการสร้างแบบจำลองที่เทียบได้กับ IDE สมัยใหม่ (สำหรับการทดสอบ การดีบัก การนำทาง ฯลฯ) สำหรับภาษาการเขียนโปรแกรมทั่วไปและภาษาเฉพาะโดเมน^{[ 9 ]}

รูปแบบที่พบได้บ่อยที่สุดของการทำงานแบบไปกลับ (round-trip engineering) คือการซิงโครไนซ์ระหว่างโมเดล UML ( Unified Modeling Language ) กับซอร์สโค้ดและไดอะแกรมความสัมพันธ์ระหว่างเอนทิตี ที่เกี่ยวข้อง ในการสร้างแบบจำลองข้อมูลและการ สร้างแบบจำลองฐานข้อมูล

การออกแบบทางวิศวกรรมแบบครบวงจรโดยใช้ภาษาสร้างแบบจำลองรวม (UML) จำเป็นต้องใช้เครื่องมือพื้นฐานสามอย่างสำหรับการพัฒนาซอฟต์แวร์:

• โปรแกรมแก้ไขซอร์สโค้ด;
• โปรแกรมแก้ไข UML สำหรับแอตทริบิวต์และเมธอด;
• การแสดงภาพโครงสร้าง UML