การสร้างแบบจำลองซอฟต์แวร์และ UML

การสร้างแบบจำลองซอฟต์แวร์เป็นการนำเสนอระบบผ่านนามธรรมที่จับโครงสร้างและพฤติกรรมของระบบ และ Unified Modeling Language (UML) เป็นสัญกรณ์กราฟิกมาตรฐานสำหรับการแสดงแบบจำลองดังกล่าว

Definition

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

Scope

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

Core questions

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

Key theories

มุมมองที่หลากหลายของระบบ

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

วิศวกรรมที่ขับเคลื่อนด้วยแบบจำลอง

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

Clinical relevance

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

Evidence & guidelines

ข้อกำหนด OMG UML กำหนดสัญกรณ์และความหมายมาตรฐาน และมาตรฐาน OMG ที่เกี่ยวข้อง เช่น SysML และ MOF ขยายการสร้างแบบจำลองไปยังวิศวกรรมระบบและเมตาโมเดลลิ่ง

History

UML เกิดขึ้นในช่วงกลางทศวรรษ 1990 จากการรวมกันของวิธีการ Booch, OMT และ Objectory ได้รับการรับรองเป็นมาตรฐาน OMG ในปี 1997 และพัฒนาผ่าน UML 2; แนวทางที่ขับเคลื่อนด้วยแบบจำลองและการร่างแบบเบา ๆ อยู่ร่วมกันกับการถกเถียงว่าการสร้างแบบจำลองที่เป็นทางการมากน้อยเพียงใดจะให้ผลตอบแทน

Debates

การพัฒนาที่ขับเคลื่อนด้วยแบบจำลองแบบหนักเทียบกับการร่างแบบเบา

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

Key figures

• Grady Booch
• James Rumbaugh
• Ivar Jacobson
• Martin Fowler

Seminal works

• booch2005
• omg2017uml
• fowler2003

Frequently asked questions

UML ยังคงมีความเกี่ยวข้องกับการพัฒนาแบบ Agile หรือไม่?

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

การสร้างแบบจำลองต้องใช้ UML หรือไม่?

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