วิธีเอกสารโครงสร้างระดับสูงของโปรแกรม Java?


20

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

  • Javadocs สำหรับแต่ละชั้นเรียนและวิธีการ
  • วิธีใช้รหัส
  • อธิบายโครงสร้างระดับสูงของรหัส

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

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

สิ่งที่ฉันได้ทำไปแล้ว

ภาษาที่แพร่หลาย

เราใส่คำอธิบาย "ภาษาที่แพร่หลาย" ของรหัสลงในไฟล์ubiquitous-language.mdเนื้อหาด้านล่าง

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

ในแต่ละช่วงเวลาเหตุการณ์ต่อไปนี้จะเกิดขึ้น:

  1. หากการจัดส่งมีกำหนดที่จะมาถึงโรงงานในช่วงเวลาปัจจุบันระดับสินค้าคงคลังของโรงงานจะเพิ่มขึ้นตามหน่วย X
  2. หากกำหนดการแสดงให้เห็นว่าในงวดปัจจุบันเป็นระยะเวลาที่รายงานจากนั้นสถานที่ยื่นรายงานไปยัง ผู้จัดจำหน่าย ซัพพลายเออร์ที่อาจได้รับรายงาน ทันทีหรือมีความล่าช้าหลายสัปดาห์ที่ผ่านมาตามที่ระบุโดยกำหนดการ
  3. หากซัพพลายเออร์ได้รับรายงานจากนั้นขึ้นอยู่กับ นโยบายการเติมเต็มมันจะคำนวณปริมาณการเติมเต็มของหน่วย X การจัดส่งหน่วย X ของผลิตภัณฑ์จะถูกกำหนดให้มาถึงหลังจากเวลานำของรอบระยะเวลา l
  4. ลูกค้ามาถึงโรงงานและต้องการหน่วย X ของผลิตภัณฑ์ ความต้องการที่ไม่ได้คาดหวังใด ๆ จะสูญหายไป

โครงสร้างรหัสต้นฉบับ

เราใส่คำอธิบาย "ระดับสูง" ที่ไม่สมบูรณ์ของรหัสลงในไฟล์structure.mdเนื้อหาด้านล่าง

โครงสร้างระดับแพ็คเกจ

ในระดับสูงสุดซอร์สโค้ดจะถูกจัดระเบียบเป็นสามแพ็คเกจ

  • com.gly.sfs คลาสหลักที่มีmainเมธอดอยู่ในแพ็คเกจนี้
  • com.gly.sfs.model คลาสโมเดลโดเมนอยู่ในแพ็คเกจนี้
  • com.gly.sfs.util คลาสตัวช่วยอยู่ในแพ็คเกจนี้


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

อุปกรณ์ประกอบฉากขนาดใหญ่สำหรับปล่อยรหัสทางวิชาการ
เฟลิกซ์

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

1
คุณอาจต้องการเพิ่ม javadoc ในระดับแพ็คเกจด้วย
haylem

คำตอบ:


4

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

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

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

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

http://omarfrancisco.com/wp-content/uploads/2011/07/sequencediagram.png

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

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

http://www.f5systems.in/apnashoppe/education//img/chapters/uml_class_diagram.jpg

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

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

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


18

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

A picture is worth a thousand words.

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

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


+1, ตัวอย่างโค้ดของงานทั่วไปคือสิ่งแรกที่ทุกคนพยายามเรียนรู้ API จะเป็นไปได้ Javadocs และรายละเอียดของความสัมพันธ์ระหว่างคลาสจะเติมลงในช่องว่าง แต่ไม่เพียงพอ
Doval

6
+1 สำหรับการไม่กล่าวถึง UML
Doc Brown

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

@DocBrown ทำไม UML จะเป็นทางออกที่ไม่ดีในกรณีนี้
Onno

@ ไม่: นี่เป็นเรื่องน่าขันเล็กน้อยของฉัน แต่ฉันคิดว่า UML มีการสนับสนุนที่ จำกัด สำหรับคำอธิบาย "ระดับสูง" และความหมายที่ไม่ชัดเจนมาก แต่ฉันเดาว่าการใช้แผนภาพแพคเกจจะใช้ได้ที่นี่ (ตราบใดที่เครื่องมือ UML อนุญาตให้วาดคลาสภายในแพ็คเกจ)
Doc Brown

3

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


1

ฉันพบhttps://www.websequencediagrams.com/เป็นเครื่องมือที่มีประโยชน์อย่างยิ่งสำหรับการอธิบายการโต้ตอบระหว่างส่วนประกอบภายในแอปพลิเคชันหรือระหว่างบริการในแอปพลิเคชันแบบกระจาย มันแค่ทำให้กระบวนการสร้างและรักษาไดอะแกรมลำดับ UML ง่ายขึ้นมาก

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

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

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