คำถามติดแท็ก modeling

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

57 design  modeling  user-experience  front-end 

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

26 readability  paradigms  data-warehouse  modeling  dependency-analysis 

ฉันได้อ่านบทความจำนวนมากเมื่อเร็ว ๆ นี้ที่อธิบายครอบงำจิตใจดั้งเดิมเป็นกลิ่นรหัส มีประโยชน์สองประการในการหลีกเลี่ยงความหลงใหลดั้งเดิม: ทำให้โมเดลโดเมนชัดเจนยิ่งขึ้น ตัวอย่างเช่นฉันสามารถพูดคุยกับนักวิเคราะห์ธุรกิจเกี่ยวกับรหัสไปรษณีย์แทนที่จะเป็นสตริงที่มีรหัสไปรษณีย์ การตรวจสอบทั้งหมดอยู่ในที่เดียวแทนที่จะใช้ข้ามแอปพลิเคชัน มีบทความมากมายที่อธิบายเมื่อมันเป็นกลิ่นรหัส ตัวอย่างเช่นฉันสามารถเห็นประโยชน์ของการลบความหลงใหลดั้งเดิมสำหรับรหัสโพสต์เช่นนี้: public class Address { public ZipCode ZipCode { get; set; } } นี่คือตัวสร้างของรหัสไปรษณีย์: public ZipCode(string value) { // Perform regex matching to verify XXXXX or XXXXX-XXXX format _value = value; } คุณจะทำลายหลักการDRYโดยวางตรรกะการตรวจสอบความถูกต้องทุกที่ที่ใช้รหัสไปรษณีย์ อย่างไรก็ตามสิ่งที่เกี่ยวกับวัตถุต่อไปนี้: วันเดือนปีเกิด: ตรวจสอบว่ามากเกินใจและน้อยกว่าวันนี้วันที่ เงินเดือน: ตรวจสอบว่ามากกว่าหรือเท่ากับศูนย์ คุณจะสร้างวัตถุ DateOfBirth และวัตถุเงินเดือนหรือไม่ ประโยชน์คือคุณสามารถพูดคุยเกี่ยวกับพวกเขาเมื่ออธิบายรูปแบบโดเมน …

22 c#  domain-driven-design  domain-model  abstraction  modeling 

นี่เป็นสถานการณ์ทั่วไปที่ทำให้ฉันต้องจัดการ ฉันมีโมเดลวัตถุที่มีวัตถุแม่ พาเรนต์มีวัตถุย่อยบางอย่าง บางสิ่งเช่นนี้ public class Zoo { public List<Animal> Animals { get; set; } public bool IsDirty { get; set; } } แต่ละวัตถุลูกมีข้อมูลและวิธีการต่าง ๆ public class Animal { public string Name { get; set; } public int Age { get; set; } public void MakeMess() { ... } } …

22 object-oriented  modeling 

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

22 uml  modeling 

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

20 design  architecture  uml  modeling 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพเมื่อ 8 ปีที่แล้วปีที่ผ่านมา เรามีผลิตภัณฑ์มีอายุยืนยาวมาประมาณ 8 ปีแล้ว เมื่อเวลาผ่านไปชื่อของแนวคิดและเอนทิตีเปลี่ยน เราควรให้งานเปลี่ยนชื่อรหัสฐานและตารางและคอลัมน์ฐานข้อมูลทั้งหมดเพื่อให้ตรงกับชื่อใหม่เหล่านี้หรือไม่ มีการศึกษาเกี่ยวกับวิธีปฏิบัติที่ดีที่สุดนี้หรือตีพิมพ์บ้างหรือไม่? ขอบคุณ

20 naming  modeling  marketing 

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

18 design  functional-programming  uml  modeling 

สำหรับคนไอทีจำนวนมากรวมถึงตัวผมเองเมื่อไม่กี่ปีที่ผ่านมากระบวนการพัฒนาซอฟต์แวร์ที่เหมาะสมจะเกี่ยวข้องกับการสร้างเอกสารการออกแบบอย่างละเอียดพร้อมไดอะแกรม UML จำนวนมากก่อนที่จะมีการเขียนบรรทัดโค้ด (ดูเหมือนว่าคำอธิบายของโมเดลน้ำตก แต่จะเหมือนกันกับว่องไวยกเว้นว่าการทำซ้ำจะเล็กกว่า) ในช่วงสองหรือสามปีที่ผ่านมาฉันเปลี่ยนใจโดยสิ้นเชิง ฉันยังคิดว่าข้อกำหนดรายละเอียดความต้องการพร้อมกรณีทดสอบที่เกี่ยวข้องนั้นเป็นสิ่งจำเป็นอย่างยิ่ง สำหรับโครงการขนาดใหญ่ฉันก็ต้องการโครงร่างของสถาปัตยกรรมโดยรวมก่อนที่จะเริ่มโค้ด แต่ส่วนที่เหลือทั้งหมดควรทำในรหัสมากที่สุด ในกรณีที่เหมาะสมไม่ควรมีคำอธิบายของการออกแบบซอฟต์แวร์ยกเว้นรหัสเอง ฉันมาถึงข้อสรุปนี้ได้อย่างไร นี่คือข้อโต้แย้งบางอย่าง: ผลตอบรับ เครื่องมือสำหรับการเขียนเอกสารหรือสร้างไดอะแกรมนั้นให้ผลป้อนกลับเล็กน้อย ใช่มีเครื่องมือสร้างแบบจำลองที่ทำการตรวจสอบความสอดคล้องบนไดอะแกรม UML แต่มีข้อ จำกัด และมาพร้อมกับค่าใช้จ่ายจำนวนมาก หากไม่มีข้อเสนอแนะมันเป็นการยากที่จะรับรู้และแก้ไขข้อผิดพลาด ทันทีที่คุณเขียนรหัสคุณจะได้รับข้อเสนอแนะมากมายเช่น: ข้อผิดพลาดและคำเตือนจากคอมไพเลอร์ ผลการวิเคราะห์รหัสคงที่ การทดสอบหน่วย สามารถจดจำและแก้ไขข้อผิดพลาดได้อย่างรวดเร็ว ความมั่นคง เพื่อให้แน่ใจว่ารหัสสอดคล้องกับเอกสารของคุณคุณต้องตรวจสอบอีกครั้งและอีกครั้ง หากมีการเปลี่ยนแปลงบ่อยครั้งจะเป็นการยากที่จะทำให้รหัสและเอกสารตรงกัน refactoring มีเครื่องมือและเทคนิคที่มีประสิทธิภาพสำหรับการ refactoring code ในขณะที่การ refactoring textual description หรือไดอะแกรมมักจะยากและเกิดข้อผิดพลาดได้ง่าย มีเงื่อนไขหนึ่งที่จะทำให้งานนี้: รหัสจะต้องง่ายพอที่จะอ่านและทำความเข้าใจ สิ่งนี้อาจไม่สามารถทำได้ด้วย Assembler, Basic หรือ Fortran แต่ภาษาสมัยใหม่ (และห้องสมุด) มีความหมายมากกว่า ดังนั้นหากข้อโต้แย้งของฉันถูกต้องควรมีแนวโน้มไปสู่ข้อกำหนดและเอกสารการออกแบบซอฟต์แวร์ที่มีน้ำหนักเบาหรือน้อย มีหลักฐานเชิงประจักษ์สำหรับแนวโน้มนี้หรือไม่?

16 design  programming-languages  development-process  modeling 

คำถามนี้จะคล้ายกับคนนี้แต่คำตอบไม่ตรงกับความต้องการของฉัน มันมุ่งเน้นไปที่เครื่องมือ UML เฉพาะ (Papyrus) ในขณะที่คำถามของฉันเป็นเรื่องทั่วไปเกี่ยวกับ UML ฉันต้องการที่จะเป็นตัวแทนของการกระทำที่ซ้อนกันในแผนภาพกิจกรรมแต่ฉันไม่ทราบว่าวิธีการทำมันคืออะไร แนวคิดคือมีการกระทำในขอบเขตเดียวกันมากกว่าการกระทำอื่น แต่มีความซับซ้อนในการดำเนินการ ฉันต้องการแสดงรายละเอียดเพิ่มเติมเกี่ยวกับการดำเนินการของมันในขณะที่ยังสามารถแสดงการกระทำนี้ในระดับเดียวกันกว่าที่อื่น ๆ ในตัวอย่างด้านล่างซึ่งเป็นแผนภาพกิจกรรมที่แสดงกิจกรรม " กลับบ้าน " บางอย่างการกระทำที่ซ้อนกันอยู่ในการPet the catดำเนินการ โปรดทราบว่ามีข้อผิดพลาดที่อาจเกิดขึ้นอีกในแผนภาพนี้ดูข้อผิดพลาดในตอนท้ายของคำถาม ฉันได้ใช้โหนดที่มีโครงสร้าง แต่ฉันไม่แน่ใจว่ามันเป็นวิธีที่ถูกต้องดังนั้นคำถาม ในสถานะชาร์ตเทียบเท่าจะเป็นคอมโพสิต แต่ฉันก็ไม่สามารถหาอะไรเกี่ยวกับคอมโพสิตแอ็คชั่น เกี่ยวกับโหนดที่มีโครงสร้างหลังจากอ่านเอกสารสองสามฉบับเกี่ยวกับมันฉันยังไม่เข้าใจว่ามันควรจะใช้อย่างไรดังนั้นฉันอาจผิดทั้งหมดกับแผนภาพนี้ ฉันรู้ด้วยว่ามีความเป็นไปได้ที่จะอ้างถึงกิจกรรมย่อยอื่นที่มีสัญลักษณ์ตรีศูลตามภาพด้านล่าง แต่มันไม่ตรงกับความต้องการของฉันเพราะฉันต้องการข้อมูลทั้งหมดในแผนภาพเดียวกัน (ดังนั้นฉันจึงสามารถพิมพ์ได้ มันโดยไม่สูญเสียข้อมูลใด ๆ ): ดังนั้นวิธีมาตรฐานในการเป็นตัวแทนของการกระทำที่ซ้อนกันคืออะไร? ตามมาตรฐานฉันหมายถึง UML ที่ถูกต้องที่เห็นได้ทั่วไปและหากเป็นไปได้สามารถทำได้ในเครื่องมือออกแบบ UML ส่วนใหญ่ errata ที่ไม่เกี่ยวข้อง: มีอีกอย่างหนึ่งที่ผิดในแผนภาพของฉันลูกศรที่เข้ามาสู่การกระทำแบบเดียวกัน ( Scratch behind the ears) ควรไปที่โหนดที่รวมกันก่อนที่จะเข้าสู่การกระทำ ดูความคิดเห็นด้านล่างรวมทั้งคำพูดของ JOT

16 uml  modeling 

ฉันกำลังจะเริ่มโครงการจำลองสถานการณ์ / การสร้างแบบจำลอง ฉันรู้อยู่แล้วว่า OOP ใช้สำหรับโครงการประเภทนี้ อย่างไรก็ตามการเรียน Haskell ทำให้ฉันพิจารณาใช้กระบวนทัศน์ของ FP สำหรับการสร้างแบบจำลองระบบของส่วนประกอบ ให้ฉันทำอย่างละเอียด: สมมติว่าฉันมีองค์ประกอบประเภท A ซึ่งมีลักษณะเป็นชุดข้อมูล (พารามิเตอร์เช่นอุณหภูมิหรือความดัน PDE และเงื่อนไขขอบเขต ฯลฯ ) และส่วนประกอบประเภท B ซึ่งมีชุดข้อมูลแตกต่างกัน (แตกต่างกัน หรือพารามิเตอร์เดียวกัน PDE และเงื่อนไขขอบเขตที่แตกต่างกัน) สมมติว่าฟังก์ชั่น / วิธีการที่จะนำไปใช้กับแต่ละองค์ประกอบเหมือนกัน (ตัวอย่างวิธี Galerkin) สถานะที่ไม่แน่นอนของวัตถุจะถูกใช้สำหรับพารามิเตอร์ที่ไม่คงที่ ถ้าฉันจะใช้วิธีการของ OOP ฉันจะสร้างวัตถุสองชนิดที่จะห่อหุ้มข้อมูลของแต่ละประเภทวิธีการในการแก้ไข PDE (การสืบทอดจะใช้ที่นี่เพื่อนำโค้ดกลับมาใช้ใหม่) และวิธีแก้ปัญหากับ PDE ในทางตรงกันข้ามถ้าฉันจะใช้วิธีการ FP แต่ละองค์ประกอบจะถูกแบ่งออกเป็นส่วนข้อมูลและฟังก์ชั่นที่จะดำเนินการกับข้อมูลเพื่อให้ได้โซลูชั่นสำหรับ PDE พารามิเตอร์ที่ไม่คงที่จะถูกส่งผ่านเป็นฟังก์ชั่นของอย่างอื่น (เวลาเช่น) หรือแสดงโดยความไม่แน่นอนบางอย่าง (การเลียนแบบความไม่แน่นอน ฯลฯ ) …

12 c++  object-oriented  functional-programming  haskell  modeling 

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

9 documentation  design  modeling 

สมมติว่าฉันมีสถานการณ์ที่ฉันออกแบบเว็บไซต์สำหรับผู้ค้าปลีกรองเท้า พวกเขามีแบรนด์และรองเท้าที่แตกต่างกันและแน่นอนว่าพวกเขาต้องการฟังก์ชั่นการค้นหาที่ดีจริงๆ ดังนั้นจึงมีคุณสมบัติแตกต่างกันที่รองเท้าสามารถมีได้ พวกเขาสามารถมีคุณสมบัติพิเศษเช่นขนาดความกว้างเพศและเด็ก / ผู้ใหญ่ หรือพวกเขาอาจมีคุณสมบัติที่ไม่พิเศษเช่นสี (อาจมีสองสีหรือมากกว่าบนรองเท้า) บางประเภทอาจขัดแย้งกับคนอื่นเช่น 'แต่งตัว' และ 'ไม่เป็นทางการ' (รองเท้าไม่สามารถเป็นได้ทั้งรองเท้าแต่งตัวและรองเท้า (ไม่สนใจรองเท้า "สบาย" สำหรับตัวอย่างนี้)) ในขณะที่พวกเขายังไม่ขัดแย้งกับ อื่น ๆ เช่น 'dress' และ 'boot' (รองเท้าสามารถเป็น boot boot) คุณสมบัติพิเศษนั้นง่ายต่อการสร้างแบบจำลอง แต่จะมีคุณสมบัติที่ขัดแย้งกันอย่างไร นี่จะเป็นปัญหาสำหรับทฤษฎีเซตหรือไม่? โดยทั่วไปแล้ววิทยาการคอมพิวเตอร์แบบนี้จะเรียกว่าอะไร? การสร้างแบบจำลองข้อมูลหรืออะไรที่เฉพาะเจาะจงกว่านี้? ฉันต้องการได้รับหลักการทางปรัชญาที่เป็นนามธรรมมากขึ้นเช่นคุณสมบัติพิเศษและไม่ผูกขาดและดูว่าหลักการเหล่านั้นนำไปใช้ในโค้ดโครงสร้างข้อมูลและสคีมาฐานข้อมูลได้อย่างไร เป็นตัวอย่างที่ดีของสิ่งที่ผมกำลังพูดถึงจะเป็นpreorder ขั้นตอนวิธีการแก้ไข มันเป็นวิธีที่ยอดเยี่ยมในการสร้างระบบการจัดหมวดหมู่แบบลำดับชั้นซ้อนกัน ดังนั้นคุณจึงมีปัญหาองค์กรในชีวิตจริง: หมวดหมู่แล้วคุณมีโครงสร้างข้อมูลที่เป็นแบบจำลองปัญหานั้น ฉันจะเรียนรู้เพิ่มเติมเกี่ยวกับสิ่งประเภทนี้ได้ที่ไหน

9 data-structures  modeling