ทำไมเราทุกคนถึงไม่พัฒนาแบบจำลองที่ขับเคลื่อนด้วยล่ะ [ปิด]

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

ฉันก็รู้ว่ามีปัญหามากมาย

• การกำหนดเวอร์ชันของเครื่องกำเนิดแม่แบบและกรอบงาน
• โครงการที่ไม่เหมาะสมสำหรับการพัฒนาแบบจำลอง (การทำซ้ำไม่เพียงพอ)
• ความเสี่ยงที่สูงขึ้น (เมื่อโครงการแรกล้มเหลวคุณมีผลลัพธ์น้อยกว่าที่คุณมีกับการพัฒนาแบบดั้งเดิมมากขึ้น)
• ฯลฯ

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

คำถาม : อะไรที่คุณเห็นว่าเป็นปัญหาที่ใหญ่ที่สุดที่ทำให้คุณไม่ได้พิจารณาการพัฒนาแบบจำลอง?

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

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

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

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

นี่คือรายการเหตุผลของฉัน:

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

มันได้รับการอ้างถึงแล้ว แต่ไม่มีกระสุนเงินที่อยู่ในจุดที่ค่อนข้างดี:

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

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

หากเป็นจริงการสร้างซอฟต์แวร์จะเป็นเรื่องยากเสมอ ไม่มีสัญลักษณ์สีเงิน

ต่อมาบรูกส์ชี้ให้เห็นต่อไปนี้เกี่ยวกับแนวคิดของ "การเขียนโปรแกรมอัตโนมัติ":

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

Parnas บอกเป็นนัยว่าคำนี้ใช้สำหรับความเย้ายวนใจไม่ใช่สำหรับความหมายของเนื้อหาอ้างว่า "ในระยะสั้นการเขียนโปรแกรมอัตโนมัติมักจะเป็นคำนิยมสำหรับการเขียนโปรแกรมด้วยภาษาระดับสูงกว่าในปัจจุบันมีโปรแกรมเมอร์"

เขาให้เหตุผลว่าในกรณีส่วนใหญ่มันเป็นวิธีการแก้ปัญหาไม่ใช่ปัญหาซึ่งจะต้องมีการกำหนด

โดยพื้นฐานแล้วฉันขอยืนยันว่า MDD เป็นเพียงถ้อยคำสละสลวยสำหรับการเขียนโปรแกรมด้วยภาษาระดับสูงกว่าที่มีอยู่ก่อนหน้านี้

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

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

เพราะมีโปรแกรมเมอร์อย่างผมที่ได้รับความก้าวหน้าและผลลัพธ์จาก TDD มากกว่า MDD

เพราะแบบจำลอง! = การเขียนโปรแกรม

เนื่องจากต้นทุน / ผลประโยชน์สูงเกินไปในด้านต้นทุนและไม่เพียงพอในด้านผลประโยชน์ สิ่งนี้อาจมีการเปลี่ยนแปลงตั้งแต่ฉันดู MDD ครั้งล่าสุดคุณต้องจ่าย> $ 6,000 / ที่นั่ง (USD) สำหรับเครื่องมือที่จะสามารถใช้ MDD ได้พอสมควร

เพราะรูปแบบที่อธิบายฟังก์ชั่นการสร้างรหัสได้อย่างเพียงพอนั้นไม่มีประโยชน์เหมือนแบบจำลองอีกต่อไป

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

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

Microsoft / Apple / Google ไม่ได้ผลักมัน :)

การพัฒนาแบบไหนที่ได้รับความนิยมมีส่วนเกี่ยวข้องกับเครื่องมือผู้สนับสนุนและการประกาศ มันยากมากที่จะบุกทะลุผ่านบางสิ่งโดยไม่ต้องมีแบ็คแฮนด์ขนาดใหญ่ (Ruby on rails อาจเป็นข้อยกเว้น แต่ก็ยังเล็กเมื่อเทียบกับ Java / C # / Python)

เนื่องจากกฎหมายง่าย ๆ ที่มีผลต่อเครื่องมือสร้างแบบจำลองเหล่านี้ทั้งหมดคุณก็รู้ CASE, UML และ:

รับระหว่างโปรแกรมเมอร์และรหัสของเขามีราคาแพงมาก

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

หนึ่งในข้อมูลเชิงลึกที่ยอดเยี่ยมของการออกแบบการขับเคลื่อนด้วยโดเมนคือโมเดลควรมีรหัสไม่ใช่สิ่งที่อยู่นอกรหัส

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

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

แต่ฉันไม่ชอบวิธีแก้ปัญหาโดยทั่วไป

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

ข้อเสียของ MDA คืออย่างที่ฉันรู้:

• การสนับสนุนการปรับโครงสร้างที่ขาดหายไป: ให้เดาว่าฉันต้องการทำโมเดลเอนทิตีของ datamodel ของฉันด้วย MDA (หมายเลข usecase ทั่วไปหมายเลข 1) ถ้าฉันมีโมเดลของฉันสมมติว่าเป็นแผนภาพ UML และฉันเปลี่ยนมันไม่มีอะไรเปลี่ยนแปลงรหัสของฉันกับมัน (อย่างน้อยคลาสที่สร้างขึ้น) และแทนที่จะมีแอพที่ใช้งานได้ที่มีคุณสมบัติชื่อที่ดีกว่าฉันจะได้รับ ข้อผิดพลาดมากมายฉันต้องแก้ไขด้วยตนเอง
• การสนับสนุนการดีบักที่ขาดหายไป: โดยปกติการแปลจากแบบจำลองเป็นรหัสจะทำโดยมีภาษาการแปลงอยู่ในมือ สิ่งนี้จะไม่มีปัญหา แต่เมื่อเราทำการดีบั๊กเราอย่างดีที่สุดไม่ควรกังวลเกี่ยวกับโค้ดที่เราสร้างขึ้นและนักดีบั๊กควรก้าวเข้าสู่โมเดลการแปลง แทนที่จะทำตามขั้นตอนในรหัสที่สร้างขึ้นและอย่างที่เรารู้กันว่าการแปลงควรดูดีไม่ใช่รหัสที่สร้างขึ้น Okey เราสามารถพิมพ์ได้ แต่ในโลกที่ดีที่สุดรหัสที่สร้างขึ้นนั้นเป็นสิ่งประดิษฐ์คอมไพเลอร์และไม่ควรเปิดในโปรแกรมแก้ไขสำหรับเซสชันดีบั๊ก (ฉันสามารถอยู่กับมันได้และเหตุผลนี้เป็นบิตตามหลักเหตุผล แต่มันเป็นหนึ่งในเหตุผลกับ MDA)
• โมเดลที่มีรหัสเป็นเรื่องง่าย: ในตัวอย่างอื่น ๆ ตัวแบบสามารถสร้างแบบจำลองบางแง่มุมของโดเมนและจากนั้นจะรวบรวมเป็นรหัส ใช่เป็น MDA แต่รุ่น MDA ส่วนใหญ่เป็นเพียงไฟล์การกำหนดค่าที่ซับซ้อนซึ่งสามารถจัดการได้อย่างง่ายดายในขณะทำงาน
• การแปลงเป็นเรื่องยากที่จะทดสอบ: ถ้าคุณใช้การแปลงใน IDE แบบพิเศษพวกเขาจะทำโดย IDE "คอมไพเลอร์" แต่การเปลี่ยนแปลงจะต้องถูกมองว่าเป็นส่วนหนึ่งของรหัสแอปพลิเคชันและเช่นนั้นควรได้รับการทดสอบและข้อกำหนดการครอบคลุมรหัสของแอป

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

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

ฉันรู้สึกว่าคนส่วนใหญ่ที่ใช้ No Silver Bullet ของ Fred Brooks เพื่ออธิบายว่าทำไมคนที่ไม่ทำ MDD พลาดจุดที่ Brooks ทำ แน่นอนว่าข้อสรุปสุดท้ายคือความซับซ้อนที่แท้จริงและแท้จริงในการพัฒนาซอฟต์แวร์จะไม่หายไปและ MDD จะไม่แก้ปัญหานี้

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

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

เปรียบเทียบแบบนี้: เขียนโปรแกรมใน C ง่ายกว่าเขียนคอมไพเลอร์ C แทนที่จะเพียงแค่แก้ปัญหาและจัดการกับ cruft ในภาษาวัตถุประสงค์ทั่วไปการสร้างสภาพแวดล้อม MDD สำหรับนักพัฒนาคนอื่นต้องการให้คุณเขียนโปรแกรมที่สามารถแก้ปัญหา cruft ที่เกี่ยวข้องกับปัญหาพื้นที่ด้านหน้าได้ มันค่อนข้างท้าทาย

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

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

นอกจากนี้นักพัฒนาสามารถสั่งให้แบบจำลองเพื่อใช้รหัสเป็น HSM เชิงเหตุการณ์หรือรูปแบบการออกแบบอื่น ๆ เหนือรูปแบบการออกแบบอื่น ๆ (หรือรูปแบบการต่อต้าน) หากรหัสนั้นได้รับการปรับปรุงด้วยตนเองเพื่อใช้รูปแบบการออกแบบที่ไม่รู้จักโมเดลนั้นสามารถอธิบายได้อย่างถูกต้องหรือไม่

คุณจะใช้ฟังก์ชั่นเหล่านั้นที่ไม่เข้ากับโมเดลได้อย่างไร

คำตอบสั้น ๆ …เนื่องจากตัวขับเคลื่อนแบบจำลองมักเกี่ยวข้องกับการสร้างรหัสและรหัสนั้นบอบบาง สิ่งที่เราต้องการคือการกำจัดรหัสและการขับเคลื่อนโมเดลย่อมเป็นหนทางที่แน่นอน

บางคนไม่สนใจคำถามที่พิสูจน์ว่าไม่มีค้อนสีทองและการพัฒนาซอฟต์แวร์นั้นซับซ้อนอย่างแท้จริง

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

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

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

วันนี้ความซับซ้อนทั้งหมดที่หลอกหลอนการพัฒนาระบบสารสนเทศและทำให้เกิดความล้มเหลวและเอวเป็นความซับซ้อนของพิธีการ ความซับซ้อนที่สามารถกำจัดได้

ความซับซ้อนของพิธีกรรมคือของเสีย, ของเสียที่เกิดจากรหัส, ค่าน้อยลง, เปลี่ยนสิ่งที่ไม่พึงประสงค์, รหัสที่ไม่เปลี่ยนแปลง รหัสที่ต้องลดให้เหลือน้อยที่สุด

ทำอย่างไร ง่าย ๆ อย่าเพิ่งเขียนมันและอย่าสร้างมันขึ้นมาตั้งแต่แรก!

จำเป็นทางเทคนิครหัสคงที่; รหัสที่ใช้สำหรับการอ่าน / การเขียนการแสดงการสื่อสาร…นั่นคือสิ่งที่แบบจำลองเข้ามาโดยการอธิบายโครงสร้างตรรกะของข้อมูล - ฉันจะเพิ่มในลักษณะเชิงสัมพันธ์ - แบบจำลองสามารถเปิดใช้งานการจัดการทั่วไปของการอ่าน / การเขียนมาตรฐาน ข้อมูล.

มันเหมือนกับระบบปฏิบัติการคุณไม่ต้องเขียนซ้ำสำหรับทุกโครงการที่คุณใช้ ดังนั้นสิ่งที่จำเป็นคือกลไกทางเทคนิคที่จัดการกับลักษณะที่คงที่ของซอฟต์แวร์ที่กำหนดแบบจำลอง ฉันเรียกมันว่าเอ็นจิ้น AaaS (Architecture as a Service)

สำหรับโค้ดที่ไม่จำเป็นมันเป็นโค้ดที่ไม่จำเป็นดังนั้นอาจทิ้งไว้ไม่ได้เขียน

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

การกำจัดรหัสที่เปราะบางทำให้เราสามารถโอบกอด Architecture as a Service เป็นกระบวนทัศน์ใหม่สำหรับการพัฒนาซอฟต์แวร์ซึ่งมีพื้นฐานจากการสร้างแบบจำลองและการออกแบบมากกว่าในโค้ด

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

เปรียบเทียบสิ่งนี้กับสาขาวิศวกรรมอื่น ๆ เช่นนักพัฒนาฮาร์ดแวร์ฝังตัวหรือวิศวกรควบคุมที่นักเรียนได้รับประสบการณ์ที่แตกต่างกันมาก ด้วยเครื่องมืออย่าง Simulink หรือ Labview นักเรียนสามารถวาดแบบจำลองจากนั้นมันก็สร้างโค้ดให้คุณหรืออย่างน้อยคุณก็สามารถรันมันในแบบจำลองได้

ในมหาวิทยาลัยที่ผ่านมาสอนคอมไพเลอร์และ parsers แต่ตอนนี้พวกเขาควรสอนวิธีการสร้างเครื่องกำเนิดใช้ DSLs ฯลฯ

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

สิ่งที่ฉันทำคือการใช้ UML ในระดับที่สูงขึ้นของนามธรรมเพื่อสร้างโครงกระดูกของใบสมัครของฉัน ฉันหมายถึงสร้างแพ็คเกจคลาส ฯลฯ ... จากนั้นเริ่มรหัสในภาษาจาวาทันที

ฉันพบว่าการซิงโครไนซ์สดกับเครื่องมือเช่น Togethersoft, Omondo มีประโยชน์จริง ๆ เมื่อฉันเริ่มการสร้างแบบจำลองเป็นครั้งแรกในปี 2004 สเตจใหม่เพิ่งได้รับการแนะนำโดย Omondo ซึ่งเป็นการทำแผนที่ระหว่าง Java, model และ ID ฐานข้อมูล ทรงพลังจริงๆและทำงานได้ดีในโครงการของฉัน

แผนภาพ UML ของฉันช่วยฉันตอนนี้เพื่อเร่งโครงการของฉันและไม่ได้ไร้ประโยชน์อีกต่อไป :-)

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

มันเป็นเรื่องง่ายที่จะมีแบบจำลองกระบวนการทางธุรกิจ ในทางทฤษฎีแล้วคุณไม่ต้องการโปรแกรมเมอร์สำหรับสิ่งนั้นเลย แสดงให้เห็นว่าแบบฝึกหัดกับ MDE นั้นการทำให้ตัวแบบที่แท้จริงทำงานได้มันก็ซับซ้อนพอ ๆ กับการเขียนโค้ด

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

ประโยชน์ของ MDE นั้น จำกัด อยู่ที่ระบบที่มีส่วนประกอบจำนวนมากมาใช้ซ้ำ

MBSE - แบบจำลองทางวิศวกรรมซอฟต์แวร์เป็นคำที่เกี่ยวข้องมากขึ้น

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

เมื่อคุณมีกระบวนการ DSML และการแปลง / การสร้างอย่างสมบูรณ์และถูกต้องแล้วการสร้างสิ่งประดิษฐ์มาในราคาที่ต่ำมาก แต่จนกว่าคุณจะไปถึงขั้นตอนการใช้เครื่องมือที่ดีบั๊กมันจะเจ็บปวดมาก

เรื่องราวความสำเร็จส่วนใหญ่ของ MDD อยู่ในส่วนของ Product Line Engineering (PLE) ซึ่งการสร้างความต่อเนื่องของผลิตภัณฑ์ที่คล้ายคลึงกันนั้นถูกสร้างขึ้นโดยใช้เครื่องมือที่สร้างขึ้นมา แน่นอนผู้สร้างโค้ด Java จำนวนมากเป็น MDD เวอร์ชันที่ง่ายกว่า XML บางตัวในและสร้างรหัสออก

คุณเขียน:

ฉันเองก็รู้ว่ามีปัญหามากมาย ... โครงการที่ไม่เหมาะกับการพัฒนาแบบจำลอง (การทำซ้ำไม่เพียงพอ)

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

ฉันมองการพัฒนาแบบจำลองเป็นเรื่องซับซ้อนและไม่มีประสิทธิภาพสำหรับภาษาการเขียนโปรแกรมที่ไม่ดี