ประโยชน์ของการสร้างแบบจำลองระบบซอฟต์แวร์เทียบกับการทำทุกอย่างในรหัสคืออะไร?


20

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

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

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

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

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

อะไรคือข้อโต้แย้งสำหรับการสร้างแบบจำลองระบบซอฟต์แวร์ฉันหายไป?

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

ชี้แจง:

คำถามถูกระงับไว้อย่างชัดเจน ดังนั้นให้ฉันเพิ่มคำอธิบาย:

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

ฉันแสดงข้อเสียของขั้นตอนนี้ที่ทำให้ฉันสงสัยว่าทำไมคนจำนวนมาก (จากประสบการณ์ของฉัน) พิจารณาว่าเป็นวิธีที่ดีกว่าในการออกแบบซอฟต์แวร์



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

3
คุณควรรู้จักคน "ไอที" มากขึ้น หรือบางทีฉันควรจะพูดว่าคุณควรทำความคุ้นเคยกับชุมชนมากขึ้นในกลุ่มนั้น
Derek Elkins ออกจาก SE

@DocBrown: ในขณะที่คำตอบสำหรับคำถามนั้นและโดยเฉพาะอย่างยิ่งบทความที่เชื่อมโยงในความคิดเห็นของคุณให้ข้อมูลที่เกี่ยวข้องคำถามต้นฉบับแตกต่างกันมาก
Frank Puffer

@ FrankPuffer: ฉันรู้ว่าได้ลงคะแนนให้เปิดใหม่อีกครั้ง อย่างไรก็ตามฉันคิดว่าแก่นแท้ของคำถามของคุณ - "การออกแบบซอฟต์แวร์คืออะไร" และ "บทบาทของการสร้างแบบจำลองในการออกแบบซอฟต์แวร์" เป็นคำถามที่กว้างมากอาจจะกว้างเกินไปที่จะตอบคำถามที่นี่
Doc Brown

คำตอบ:


23

ประโยชน์ของการสร้างแบบจำลองระบบซอฟต์แวร์กับรหัสทั้งหมดคือ: ฉันสามารถใส่แบบจำลองบนกระดานไวท์บอร์ดได้

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

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

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

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

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

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


2
"ไม่มีรหัสใดในระดับนามธรรมที่พอดีกับไวท์บอร์ด" ซึ่งทำให้เกิดคำถามที่น่าสนใจ ทำไมจะไม่ล่ะ? อะไรจะเป็นจริงสำหรับจุดเริ่มต้นของระบบเพื่ออธิบายในระดับสูงมากว่ามันทำอะไร?
RubberDuck

2
เพราะรหัสจะต้องเป็นทุกสิ่งสำหรับทุกคน (และอย่างน้อยหนึ่งคอมไพเลอร์) แบบจำลองสามารถมีกลุ่มเป้าหมายที่มุ่งเน้นได้
candied_orange

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

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

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

6

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

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

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

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

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

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


ตัวอย่างการนับ (?) :: การแยกแบบจำลองมุมมอง (หรือรูปแบบ GoF) ใด ๆ สามารถวาดได้อย่างง่ายดายตามความจริงที่ตั้งใจของการออกแบบ (พิมพ์เขียว) ที่เสนอโดยสถาปนิก นักพัฒนาซอฟต์แวร์ที่หลงทางจากความตั้งใจนั้นไม่ได้ทำให้โมเดล (ตั้งใจ) ไร้ประโยชน์ ใช่รหัสคือ "ความจริง" แต่ไม่จำเป็นต้องออกแบบ การตรวจสอบไม่จำเป็นต้องเป็นอัตโนมัติด้วย UML หรือบางรุ่น ความจริงที่ว่ามันไม่ได้เป็นแบบอย่างที่ดี
Fuhrmanator

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

5

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

ฉันไม่เห็นด้วยที่ทุกคนที่คุณรู้จักเชื่อเรื่องนี้ แต่ฉันไม่คิดว่ามันเป็นเรื่องธรรมดาทั่วทั้งกระดาน ในปี 1970 Winston Royce รู้ว่าการพัฒนาซอฟต์แวร์มีระดับของการวนซ้ำระหว่างการออกแบบและกิจกรรมของโค้ด ในปี 1992 แจ็ครีฟส์เขียนเกี่ยวกับการเขียนโปรแกรมเป็นกิจกรรมการออกแบบที่แท้จริง (ยังหารือเกี่ยวกับ C2 วิกิพีเดีย )

นี่ไม่ได้หมายความว่าผู้คนพยายามสร้างเครื่องมือพัฒนาแบบจำลอง มีเครื่องมือที่พยายามสร้างรหัสจากโมเดล UML (ไม่ใช่แค่คลาสไดอะแกรม แต่เชื่อมโยงชนิดไดอะแกรมต่าง ๆ เข้าด้วยกันและสร้างรหัสจากพวกเขา) แต่นั่นก็ไม่ใช่เครื่องมือที่ใช้กันอย่างแพร่หลาย

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

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

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

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

ฉันคิดว่าเป็นกฎทั่วไปการเปลี่ยนจาก model-> code เป็นวิธีที่ผิด รหัสควรสร้างแบบจำลองแทน นั่นคือเครื่องมือควรจะสามารถตรวจสอบโค้ดและสร้างการแสดงกราฟิกและตารางที่สามารถปรับปรุงเพิ่มเติมได้ในขณะที่วิศวกรเขียนข้อความรอบตัว และรุ่นของโมเดลจากโค้ดควรเป็นส่วนต่อเนื่องของกระบวนการสร้างและวางจำหน่าย

มีเครื่องมือที่สนับสนุนองศาสำหรับภาษาต่าง ๆ ด้วยธรรมชาติของภาษาและกระบวนทัศน์บางคนก็ง่ายกว่าคนอื่น

ฉันแสดงข้อเสียของขั้นตอนนี้ที่ทำให้ฉันสงสัยว่าทำไมคนจำนวนมาก (จากประสบการณ์ของฉัน) พิจารณาว่าเป็นวิธีที่ดีกว่าในการออกแบบซอฟต์แวร์

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

ประโยชน์ของการสร้างแบบจำลองระบบซอฟต์แวร์เทียบกับการทำทุกอย่างในรหัสคืออะไร?

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


5

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

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

  • ไดอะแกรมกรณีการใช้งานสามารถแสดงคุณสมบัติและการโต้ตอบกับผู้ใช้หรือระบบภายนอก ป้อนคำอธิบายรูปภาพที่นี่

  • แผนภาพกิจกรรมสามารถแสดงกระบวนการทางธุรกิจที่ซอฟต์แวร์ต้องการสนับสนุน ป้อนคำอธิบายรูปภาพที่นี่

  • ไดอะแกรมสถานะสามารถแสดงไดนามิกที่ต้องการบนเว็บไซต์: ป้อนคำอธิบายรูปภาพที่นี่

  • รูปแบบการออกแบบ Gang of Four ถูกนำเสนอเป็นแบบคงที่และแบบไดนามิก ตัวอย่างเช่นของที่ระลึก:
    ป้อนคำอธิบายรูปภาพที่นี่
    ป้อนคำอธิบายรูปภาพที่นี่

ฉันแสดงข้อเสียของขั้นตอนนี้ที่ทำให้ฉันสงสัยว่าทำไมคนจำนวนมาก (จากประสบการณ์ของฉัน) พิจารณาว่าเป็นวิธีที่ดีกว่าในการออกแบบซอฟต์แวร์

หากคุณสนใจข้อมูลจริงเกี่ยวกับการใช้งาน UML นอกประสบการณ์ของคุณมีการศึกษาบางอย่างที่ทำ (ฉันพยายามค้นหาลิงก์ไปยังบทความที่ไม่ใช่ paywall):

  • Petre, Marian (2013) UML ในการปฏิบัติ ใน: การประชุมนานาชาติครั้งที่ 35 เกี่ยวกับวิศวกรรมซอฟต์แวร์ (ICSE 2013), 18-26 พฤษภาคม 2013, San Francisco, CA, USA, pp. 722–731
  • N. Mangano, TD LaToza, M. Petre และ A. van der Hoek (2015) วิธี Software ออกแบบโต้ตอบกับภาพวาดที่ไวท์บอร์ด ใน: ธุรกรรม IEEE เกี่ยวกับวิศวกรรมซอฟต์แวร์, ฉบับที่ 41, ไม่มี 2, pp. 135-156
  • Andrew Forward และ Timothy C. Lethbridge 2008 ปัญหาและโอกาสสำหรับรูปแบบการเป็นศูนย์กลางเมื่อเทียบกับการพัฒนาซอฟต์แวร์รหัสเป็นศูนย์กลาง: การสำรวจของผู้เชี่ยวชาญด้านซอฟต์แวร์ ในการประชุมเชิงปฏิบัติการระดับนานาชาติ 2008 เกี่ยวกับแบบจำลองในวิศวกรรมซอฟต์แวร์ (MiSE '08) พลอากาศเอกนิวยอร์กนิวยอร์กสหรัฐอเมริกา 27-32

0

นักพัฒนาเราชอบที่จะใช้รูปภาพเพื่ออธิบายโลกของเราดังนั้นที่นี่เป็นหนึ่งเดียวกับการผลิตรถยนต์:

  • รถเป็นผลมาจากห่วงโซ่การผลิตเช่นเดียวกับรหัส (เพิ่มกระบวนการปรับใช้แน่นอน)
  • เอกสารการออกแบบของรถยนต์เหมือนกับเอกสารการออกแบบของซอฟต์แวร์

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

โดยการทำให้เอกสารเหล่านั้นเป็นครั้งแรกโดยไม่ต้องเข้ารหัส (ยกเว้นสิ่งใด ๆ เช่นหลักฐานการคิดเพื่อความเป็นไปได้ ... )

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

หมายเหตุ: การยืนยันเหล่านั้นสมมติว่ารหัสเป็นภาพสะท้อนของการออกแบบจริง ๆ และพวกเขาทั้งคู่ก็ทันสมัยอยู่เสมอ ...


คำตอบนี้อธิบายสถานการณ์ที่ใกล้เคียงที่สุด คุณพูดถึงหนึ่ง caveat ในตอนท้ายที่ค่อนข้างใหญ่ด้วยตัวเอง มีอีกหลายคน คุณสามารถละเว้นด้านที่จำเป็นภายใต้การประเมินความซับซ้อนของบางส่วนที่ไม่ได้เป็นปัจจัยในการ จำกัด ห้องสมุด / กรอบคุณใช้กำหนด, ไม่ได้เป็นปัจจัยในข้อบกพร่องในการอ้างอิงไม่ได้เป็นปัจจัยในการทำงานหรือความต้องการที่ไม่ได้ทำงานอื่น ๆกว่าวิศวกร ล้มเหลวในการคาดการณ์การเปลี่ยนแปลงหรือไม่ดีในการออกแบบ สถานการณ์ที่ดีที่สุดกรณีนี้ไม่น่าจะเกิดขึ้นได้แม้ในบริบทที่เป็นมืออาชีพ
Derek Elkins ออกจาก SE

หากคุณเริ่มต้นด้วยการพิจารณาทุกข้อแม้ของทุกสิ่งคุณจะไม่ไปไหนเลย วิธีใดก็ตามที่คุณใช้ และรายการยาว ๆ ของสิ่งที่คุณพูดถูกต้องสมบูรณ์เมื่อทำโค้ดเท่านั้น
Walfrat
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.