โปรแกรมเมอร์ทำงานอะไรที่ใช้แทน UML?


18

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

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

ครูของเราเมื่อเผชิญหน้ากับ "สิ่งที่เกี่ยวกับกระบวนทัศน์การทำงาน?" คำถามตอบว่าเขาไม่ได้เขียนโปรแกรมโครงการขนาดใหญ่ในภาษาที่ใช้งานได้และเขาไม่รู้ว่าเครื่องมือที่ใช้งานได้อาจใช้โปรแกรมอะไร

ดังนั้นพวกเขาจะใช้อะไร มีวิธีการนี้ไหม หรืออาจไม่จำเป็นต้องมีสิ่งนั้น?


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

9
ฉันเป็นนักพัฒนาซอฟต์แวร์มาหลายปีแล้ว ฉันไม่เคยใช้ UML ในชีวิตของฉันเองฉันไม่เคยพบใครสักคนที่คุ้นเคยกับภาษาทั้งหมด ไดอะแกรมนั้นยอดเยี่ยมแม้ว่า ....
AK_

1
@ 9000: จริง ๆ แล้วแผนภาพกระแสข้อมูลเป็น IMHO หนึ่งในประเภทของไดอะแกรมที่มีประโยชน์ที่สุดสำหรับการอธิบายการออกแบบซอฟต์แวร์ในระดับที่เป็นนามธรรมที่สูงกว่า - มีประโยชน์มากกว่าแผนภาพคลาส สิ่งนี้ใช้ได้กับ FP และ OOP เช่นกัน น่าเสียดายที่นักประดิษฐ์ UML เลือกที่จะเพิ่มประเภทไดอะแกรมที่ไม่จำเป็นลงในภาษาการสร้างแบบจำลอง แต่ปฏิเสธที่จะเพิ่มไดอะแกรมการไหลของข้อมูล (ใช่นี่คือคำโผงผาง!)
Doc Brown

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

คำตอบ:


23

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

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

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


19

มาตรฐาน UML กำหนดประเภทไดอะแกรมต่างกันมากกว่าโหลตามที่แสดงในแผนภูมิที่มีประโยชน์นี้:

ประเภทไดอะแกรม UML

ที่มา: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg

ดูรูปที่ A.5 อนุกรมวิธานของโครงสร้างและแผนภาพพฤติกรรมในสเปค UML 2.5

โปรดทราบว่านี่เป็นตัวอย่างของคลาสไดอะแกรมที่มีความสัมพันธ์แบบย่อยระหว่างชนิดไดอะแกรมและชนิดไดอะแกรมนามธรรมเป็นตัวเอียง ในขณะที่ชนิดไดอะแกรมเหล่านี้เป็นคลาสภายใน UML metamodel ไดอะแกรมคลาสนี้ยังมีประโยชน์ในการแสดงลำดับชั้นโดยไม่มีการเชื่อมต่อกับ OOP

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

  • State Machine Diagrams - FP ไม่ได้หลีกเลี่ยงสถานะมันทำให้พวกเขาชัดเจน ไดอะแกรมเครื่องรัฐอาจมีประโยชน์ในการอธิบายโฟลว์การควบคุมหรือการเปลี่ยนสถานะต่างๆในโปรแกรม

  • Activity Diagrams - มีประโยชน์ในกรณีที่คล้ายกันกับ State Machine Diagram แต่ในระดับที่สูงขึ้น สามารถใช้เพื่ออธิบายการไหลของข้อมูลระหว่างระบบย่อยต่างๆหรือเพื่อจำลองกระบวนการทางธุรกิจภายนอก

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

  • ใช้ไดอะแกรมของเคส - การใช้เคสและข้อกำหนดเป็นอิสระจากเทคโนโลยีที่ใช้เพื่อทำให้เป็นจริง OOP หรือ FP ไม่มีความเกี่ยวข้องอย่างแน่นอนที่นี่

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

  • แผนภาพส่วนประกอบ - ภาษาที่ใช้งานได้ส่วนใหญ่มีการสนับสนุนอย่างชัดเจนสำหรับการเขียนโปรแกรมแบบแยกส่วนวันนี้ Component Diagram อธิบายส่วนประกอบ / โมดูลและอินเตอร์เฟสที่เสนอและจำเป็น ทำให้ฉันนึกถึงโมดูล Functor ของ OCaml มากมาย

  • ไดอะแกรมโปรไฟล์ - อธิบายส่วนขยายของ UML เองและไม่เคยใช้งานจริง

  • แผนภาพโครงสร้างคอมโพสิต - อธิบายโครงสร้างของคอมโพสิต สามารถใช้เพื่ออธิบายโครงสร้างข้อมูลหรือแม้แต่จุดโต้ตอบของฟังก์ชัน Wikipedia แสดงแผนภาพสำหรับฟังก์ชัน Fibonacci เป็นตัวอย่าง:

    แผนภาพโครงสร้างคอมโพสิตสำหรับ Fibonacci funciton

    ที่มา: https://commons.wikimedia.org/wiki/File:Composite_Struct_Diagram.png

    เรียกได้ว่าเป็นตัวเลือกโปรแกรมเมอร์ที่ใช้งานได้แทนที่จะเป็นแผนภาพคลาส แต่ดูเหมือนว่าจะมีการ overengineered อย่างน่ากลัว….

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

ดังที่เราได้เห็นประเภทแผนภาพ UML ต่างๆยังคงมีประโยชน์เมื่อทำการเขียนโปรแกรมการทำงาน


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

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