การออกแบบซอฟต์แวร์กับสถาปัตยกรรมซอฟต์แวร์ [ปิด]

ใครช่วยอธิบายความแตกต่างระหว่างการออกแบบซอฟต์แวร์และสถาปัตยกรรมซอฟต์แวร์ได้บ้าง

โดยเฉพาะอย่างยิ่ง; ถ้าคุณบอกใครสักคนเพื่อนำเสนอ 'การออกแบบ' คุณจะคาดหวังให้พวกเขานำเสนออะไร? กันไปสำหรับ 'สถาปัตยกรรม'

ความเข้าใจปัจจุบันของฉันคือ:

• การออกแบบ: แผนภาพ UML / แผนผังการไหล / wireframes ง่าย ๆ (สำหรับ UI) สำหรับโมดูล / ส่วนหนึ่งของระบบ
• สถาปัตยกรรม: แผนภาพองค์ประกอบ (แสดงวิธีการที่โมดูลที่แตกต่างกันของระบบสื่อสารกับระบบอื่น ๆ และอื่น ๆ ), ภาษาใดที่จะใช้รูปแบบ ... ?

ช่วยแก้ให้ด้วยนะถ้าฉันผิด. ฉันได้อ้างอิง Wikipedia มีบทความเกี่ยวกับhttp://en.wikipedia.org/wiki/Software_designและhttp://en.wikipedia.org/wiki/Software_architectureแต่ฉันไม่แน่ใจว่าฉันเข้าใจพวกเขาถูกต้องหรือไม่

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

การออกแบบซอฟต์แวร์นั้นเกี่ยวกับการออกแบบแต่ละโมดูล / ส่วนประกอบ หน้าที่ความรับผิดชอบของโมดูล x คืออะไร? ของคลาส Y มันทำอะไรได้และอะไรไม่ได้เหรอ? รูปแบบการออกแบบใดที่สามารถใช้ได้?

ดังนั้นในระยะสั้นสถาปัตยกรรมซอฟต์แวร์เป็นเรื่องเกี่ยวกับการออกแบบของระบบทั้งหมดในขณะที่การออกแบบซอฟต์แวร์จะเน้นในระดับโมดูล / ส่วนประกอบ / ระดับ

ในคำอธิบายบางอย่างของSDLC (วัฏจักรการพัฒนาซอฟต์แวร์)พวกมันสามารถใช้แทนกันได้ แต่ข้อเสียคือมันแตกต่างกัน พวกเขามีในเวลาเดียวกัน: ที่แตกต่างกัน (1) ขั้นตอน (2) พื้นที่ของความรับผิดชอบและ (3) ระดับของการตัดสินใจ

• สถาปัตยกรรมเป็นภาพที่ใหญ่กว่า: ตัวเลือกของกรอบภาษาขอบเขตเป้าหมายและระเบียบวิธีระดับสูง ( Rational , Waterfall , Agileฯลฯ )
• การออกแบบเป็นภาพขนาดเล็ก: แผนการสำหรับการจัดระเบียบโค้ด สัญญาระหว่างส่วนต่าง ๆ ของระบบจะมีลักษณะอย่างไร การดำเนินการตามวิธีการและเป้าหมายของโครงการอย่างต่อเนื่อง ข้อมูลจำเพาะจะถูกเขียนในระหว่างขั้นตอนนี้

สองขั้นตอนนี้ดูเหมือนจะผสมผสานกันด้วยเหตุผลที่แตกต่างกัน

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

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

สถาปัตยกรรมเป็นกลยุทธ์ในขณะที่การออกแบบนั้นเป็นเรื่องของยุทธวิธี

สถาปัตยกรรมประกอบด้วยเฟรมเวิร์ก, เครื่องมือ, กระบวนทัศน์การเขียนโปรแกรม, มาตรฐานวิศวกรรมซอฟต์แวร์แบบอิงองค์ประกอบ, หลักการระดับสูง ..

ในขณะที่การออกแบบเป็นกิจกรรมที่เกี่ยวข้องกับข้อ จำกัด ในท้องถิ่นเช่นรูปแบบการออกแบบสำนวนการเขียนโปรแกรมและ refactorings

ฉันพบสิ่งนี้ในขณะที่ฉันกำลังมองหาความแตกต่างง่ายๆระหว่างสถาปัตยกรรมและออกแบบเอง
คุณคิดอย่างไรกับการมองพวกเขาในลักษณะนี้:

• สถาปัตยกรรมคือ "อะไร" เรากำลังสร้าง;
• การออกแบบคือ "วิธีการ" เรากำลังสร้าง;

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

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

2. หากคุณเป็น“ สถาปนิก” ส่วนประกอบคุณกำลังกำหนดว่ามันจะทำงานอย่างไรในระบบที่ใหญ่ขึ้น

   หากคุณ“ ออกแบบ” ส่วนประกอบเดียวกันคุณกำลังกำหนดวิธีการทำงานภายใน

สถาปัตยกรรมทั้งหมดเป็นการออกแบบ แต่ไม่ใช่การออกแบบทั้งหมดคือสถาปัตยกรรม

Whatส่วนหนึ่งคือการออกแบบที่Howมีการใช้งานที่เป็นรูปธรรมและจุดตัดของWhatและHowเป็นสถาปัตยกรรม

รูปภาพสำหรับสถาปัตยกรรมและการออกแบบที่แตกต่าง :

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

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

ลิงค์ที่ให้การเปรียบเทียบที่ดี

ฉันพูดว่าคุณพูดถูก

สถาปัตยกรรมคือการจัดสรรความต้องการของระบบไปยังองค์ประกอบของระบบ สี่ข้อความเกี่ยวกับสถาปัตยกรรม:

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

สถาปัตยกรรมเป็นขั้นตอนทางวิศวกรรมที่สำคัญเมื่อความซับซ้อนของระบบถูกแบ่งย่อย

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

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

มันจะดีที่ได้เห็นการออกแบบห้องครัวเห็นก่อนที่จะมีการติดตั้งห้องครัว แต่มันไม่จำเป็นสำหรับความต้องการการปรุงอาหาร :

ถ้าฉันคิดเกี่ยวกับมันคุณสามารถระบุ:

• สถาปัตยกรรมสำหรับสาธารณะ / วิศวกรในระดับนามธรรมที่มีรายละเอียดมากขึ้น
• การออกแบบมีไว้สำหรับสาธารณะในระดับนามธรรมที่มีรายละเอียดน้อยกว่า

การแจ้งเตือนของฉัน:

• เราสามารถเปลี่ยนการออกแบบโดยไม่ต้องขอใครสักคน
• หากเราเปลี่ยนสถาปัตยกรรมเราจำเป็นต้องสื่อสารกับใครบางคน (ทีมลูกค้าผู้มีส่วนได้เสีย, ... )

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

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

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

(แยกส่วนจากhttp://www.copypasteisforword.com/notes/software-architecture-vs-software-design )

โดยส่วนตัวแล้วฉันชอบสิ่งนี้:

"นักออกแบบเกี่ยวข้องกับสิ่งที่เกิดขึ้นเมื่อผู้ใช้กดปุ่มและสถาปนิกเกี่ยวข้องกับสิ่งที่เกิดขึ้นเมื่อผู้ใช้หมื่นคนกดปุ่ม"

SCEA สำหรับคู่มือการศึกษา Java ™ EEโดย Mark Cade และ Humphrey Sheil

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

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

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

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

สถาปัตยกรรมเป็นการออกแบบ แต่ไม่ใช่การออกแบบทั้งหมดที่เป็นสถาปัตยกรรม ดังนั้นการพูดอย่างเคร่งครัดก็จะทำให้รู้สึกมากขึ้นในการพยายามที่จะแยกความแตกต่างระหว่างการออกแบบสถาปัตยกรรมและการออกแบบที่ไม่ใช่สถาปัตยกรรม และความแตกต่างคืออะไร? มันขึ้นอยู่กับ! สถาปนิกซอฟต์แวร์แต่ละคนอาจมีคำตอบที่แตกต่างกัน (ymmv!) เราพัฒนาฮิวริสติกของเราเพื่อหาคำตอบเช่น 'คลาสไดอะแกรมคือสถาปัตยกรรมและลำดับไดอะแกรมคือการออกแบบ' ดูหนังสือ DSAเพิ่มเติม

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

ดังนั้นข้อเสนอแนะของฉันคือ:

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

ต้องบอกว่า ... คำถามที่เกี่ยวข้องมากกว่าที่เราต้องถามคือ: การออกแบบเท่าไหร่พอ? นั่นคือเมื่อใดที่ฉันควรหยุดอธิบายการออกแบบ (ในแผนภาพหรือร้อยแก้ว) และควรไปยังการเข้ารหัส?

ใช่นั่นฟังดูเหมาะสมกับฉัน การออกแบบคือสิ่งที่คุณจะทำและสถาปัตยกรรมเป็นวิธีการที่ชิ้นส่วนและการออกแบบจะรวมเข้าด้วยกัน อาจเป็นผู้ไม่เชื่อเรื่องภาษา แต่โดยปกติจะระบุเทคโนโลยีที่จะใช้เช่น LAMP v Windows, Web Service v RPC

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

(จาก Wikipedia, http://en.wikipedia.org/wiki/Software_architecture )

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

(จาก Wikipedia, http://en.wikipedia.org/wiki/Software_design )

ไม่สามารถพูดได้ดีกว่านี้ :)

ฉันดูสถาปัตยกรรมเหมือนที่ Patrick Karcher ทำ - ภาพใหญ่ ตัวอย่างเช่นคุณสามารถมอบสถาปัตยกรรมให้กับอาคารดูการสนับสนุนโครงสร้างหน้าต่างทางเข้าและทางออกการระบายน้ำ ฯลฯ แต่คุณยังไม่ได้ "ออกแบบ" เลย์เอาต์พื้นตำแหน่งกุฏิ ฯลฯ

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

คุณสามารถดูการออกแบบเลย์เอาต์เป็น "การออกแบบโครงสร้าง" แม้ว่า ...

คำถามที่ดี ... แม้ว่าเส้นแบ่งระหว่างพวกเขาจะเป็นเส้นที่คมชัดแทบจะไม่, imho, ถ้าคุณใช้ทั้งสองคำ, สถาปัตยกรรมนั้นครอบคลุมการตัดสินใจทางเทคนิคหรือโครงสร้างเพิ่มเติมเกี่ยวกับวิธีการสร้างหรือสร้างบางสิ่งบางอย่างโดยเฉพาะการตัดสินใจที่จะยาก หรือยากกว่า) ในการเปลี่ยนแปลงเมื่อดำเนินการในขณะที่การออกแบบครอบคลุมการตัดสินใจเหล่านั้นซึ่งง่ายต่อการเปลี่ยนแปลงในภายหลัง (เช่นชื่อเมธอดคลาสโครงสร้างไฟล์องค์กร <-> รูปแบบการออกแบบไม่ว่าจะใช้ซิงเกิลตันหรือคลาสคงที่เพื่อแก้ปัญหาเฉพาะบางอย่าง ฯลฯ ) และ / หรือสิ่งที่มีผลต่อลักษณะที่ปรากฏหรือความสวยงามของระบบหรือแอปพลิเคชัน (Human Interface, ความง่ายในการใช้, รูปลักษณ์และความรู้สึกเป็นต้น)

สถาปัตยกรรมซอฟต์แวร์นั้น“ เกี่ยวข้องกับปัญหา ... เกินกว่าอัลกอริธึมและโครงสร้างข้อมูลของการคำนวณ

สถาปัตยกรรมไม่ได้เกี่ยวกับ…รายละเอียดของการใช้งาน (เช่นอัลกอริธึมและโครงสร้างข้อมูล) การออกแบบสถาปัตยกรรมเกี่ยวข้องกับการรวบรวม abstractions ที่สมบูรณ์กว่าที่ OOD จัดทำขึ้นโดยทั่วไป” (การออกแบบเชิงวัตถุ)

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

“ สถาปัตยกรรม” มักใช้เป็นคำพ้องความหมายสำหรับ“ การออกแบบ” (บางครั้งนำหน้าด้วยคำคุณศัพท์“ ระดับสูง”) และหลายคนใช้คำว่า "รูปแบบสถาปัตยกรรม" เป็นคำพ้องสำหรับ "รูปแบบการออกแบบ"

ลองลิงค์นี้

การกำหนดสถาปัตยกรรมข้อกำหนดการออกแบบและการใช้งาน

สถาปัตยกรรม:
งานออกแบบโครงสร้างในระดับที่สูงขึ้นของนามธรรมซึ่งตระหนักถึงความต้องการทางเทคนิคที่สำคัญในระบบ สถาปัตยกรรมวางรากฐานสำหรับการออกแบบเพิ่มเติม

การออกแบบ:
ศิลปะการเติมเต็มในสิ่งที่สถาปัตยกรรมไม่ได้ผ่านกระบวนการวนซ้ำในแต่ละชั้นของสิ่งที่เป็นนามธรรม

ฉันชอบบทความนี้มากสำหรับกฎง่ายๆเกี่ยวกับการแยกสถาปัตยกรรมออกจากการออกแบบ:

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

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

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

ค่อนข้างอัตนัย แต่ใช้ของฉัน:

สถาปัตยกรรม การออกแบบโดยรวมของระบบรวมถึงการโต้ตอบกับระบบอื่นความต้องการของฮาร์ดแวร์การออกแบบส่วนประกอบโดยรวมและการไหลของข้อมูล

การออกแบบ การจัดระเบียบและการไหลขององค์ประกอบในระบบโดยรวม ซึ่งจะรวมถึง API ขององค์ประกอบสำหรับการโต้ตอบกับส่วนประกอบอื่น ๆ

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

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

แต่เมื่อเป็นสถาปนิกซอฟต์แวร์จะให้รายละเอียดการแก้ปัญหาของเขาเขาจะตระหนักว่า:

"การประเมินผลงาน" ไม่สามารถเป็นแอปพลิเคชั่นเดียวได้ จะต้องมีการปรับปรุงในโครงการที่จัดการได้เช่น:

• GUI
• เปิด
• ผู้จัดการ
• ...

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

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

ถ้ามีคนสร้างเรือแล้วเครื่องยนต์ลำเรือวงจรไฟฟ้า ฯลฯ จะเป็น "องค์ประกอบทางสถาปัตยกรรม" ของเขา สำหรับเขาการสร้างเครื่องยนต์จะเป็น "งานออกแบบ"

หากเขามอบหมายการสร้างเครื่องยนต์ให้กับทีมอื่นพวกเขาจะสร้าง "สถาปัตยกรรมเครื่องยนต์" ...

ดังนั้น - ขึ้นอยู่กับระดับของนามธรรมหรือรายละเอียด สถาปัตยกรรมของบุคคลหนึ่งอาจเป็นการออกแบบของผู้เป็นแม่!

สถาปัตยกรรมคือ"การตัดสินใจออกแบบที่เปลี่ยนแปลงได้ยาก"

หลังจากทำงานกับ TDD ซึ่งหมายความว่าการออกแบบของคุณเปลี่ยนไปตลอดเวลาฉันมักพบว่าตัวเองต้องดิ้นรนกับคำถามนี้ คำจำกัดความข้างต้นถูกดึงมาจากPatterns of Enterprise Application Architectureโดย Martin Fowler

หมายความว่าสถาปัตยกรรมขึ้นอยู่กับภาษา, กรอบงานและโดเมนของระบบของคุณ หากคุณสามารถแยกอินเทอร์เฟซจาก Java Class ของคุณใน 5 นาทีมันจะไม่ใช่การตัดสินใจและสถาปัตยกรรม

รุ่น Cliff Notes:

ออกแบบ: การนำโซลูชันไปใช้ตามข้อกำหนดของผลิตภัณฑ์ที่ต้องการ

สถาปัตยกรรม: รากฐาน / เครื่องมือ / โครงสร้างพื้นฐาน / ส่วนประกอบที่สนับสนุนการออกแบบของคุณ

นี่เป็นคำถามที่ค่อนข้างกว้างที่จะเรียกการตอบสนองมากมาย

สถาปัตยกรรมคือชุดของผลลัพธ์ของรูปแบบการออกแบบเพื่อสร้างระบบ

ฉันคิดว่าการออกแบบเป็นความคิดสร้างสรรค์ที่นำมารวมกันทั้งหมดหรือไม่

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

นักวิชาการมักจะเห็นสถาปัตยกรรมเป็นส่วนหนึ่งของการออกแบบซอฟต์แวร์ที่ใหญ่ขึ้น แม้ว่าจะมีการรับรู้เพิ่มขึ้นเรื่อย ๆ ว่า Arch เป็นสนามที่อยู่ภายในตัวของมันเอง

ผู้ปฏิบัติงานมีแนวโน้มที่จะเห็น Arch เป็นการตัดสินใจในระดับสูงซึ่งเป็นกลยุทธ์และอาจมีค่าใช้จ่ายสูงในโครงการที่จะเลิกทำ

เส้นตรงระหว่าง Arch และการออกแบบขึ้นอยู่กับโดเมนซอฟต์แวร์ ตัวอย่างเช่นในโดเมนของ Web Applications สถาปัตยกรรมแบบเลเยอร์กำลังได้รับความนิยมมากที่สุดในปัจจุบัน (Biz Logic Layer, Data Access Layer ฯลฯ ) ส่วนที่ต่ำกว่าของ Arch นี้ถือว่าเป็นการออกแบบ (คลาสไดอะแกรมลายเซ็นวิธี ฯลฯ ) ) สิ่งนี้จะถูกกำหนดแตกต่างกันในโดเมนของระบบฝังตัวระบบปฏิบัติการคอมไพเลอร์ ฯลฯ

สถาปัตยกรรมอยู่ในระดับสูง, นามธรรมและการออกแบบเชิงตรรกะในขณะที่การออกแบบซอฟต์แวร์อยู่ในระดับต่ำรายละเอียดและการออกแบบทางกายภาพ

นอกจากนี้โปรดดูที่: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

ฉันชอบคำนิยามและคำอธิบายของ Roy Thomas Fielding เกี่ยวกับสถาปัตยกรรมซอฟต์แวร์ในกระดาษของเขา: ลักษณะสถาปัตยกรรมและการออกแบบสถาปัตยกรรมซอฟต์แวร์ที่ใช้เครือข่าย

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

เขาเน้น "องค์ประกอบของเวลาทำงาน" และ "ระดับของสิ่งที่เป็นนามธรรม"

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

วิธีคิดที่ดีคือ Len Bass, Paul Clements และ Rick Kazman กล่าวว่า "สถาปัตยกรรมทั้งหมดคือการออกแบบ แต่ไม่ใช่การออกแบบทั้งหมดคือสถาปัตยกรรม" [Software Architecture in Practice] ฉันไม่แน่ใจว่าฉันเห็นด้วยกับสิ่งนั้น (เพราะสถาปัตยกรรมสามารถรวมกิจกรรมอื่น ๆ ) แต่มันจับสาระสำคัญที่สถาปัตยกรรมเป็นกิจกรรมการออกแบบที่เกี่ยวข้องกับชุดย่อยที่สำคัญของการออกแบบ

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

ความพยายามที่มีประโยชน์ในการแยกสถาปัตยกรรมการออกแบบและการใช้งานเป็นแนวคิดที่ทำโดย Amnon Eden และ Rick Kazman เมื่อหลายปีก่อนในงานวิจัยเรื่อง "Architecture, Design, Implementation" ซึ่งสามารถพบได้ที่นี่: http: //www.sei.cmu .edu ภาษาของพวกเขาค่อนข้างเป็นนามธรรม แต่พวกเขาพูดง่าย ๆ ว่าสถาปัตยกรรมคือการออกแบบที่สามารถนำไปใช้ในหลายบริบทและมีความหมายที่จะนำไปใช้กับระบบการออกแบบคือการออกแบบ (ผิดพลาด) ที่สามารถใช้ได้ในหลายบริบท ของระบบและการนำไปใช้เป็นการออกแบบเฉพาะบริบทและนำไปใช้ในบริบทนั้น

ดังนั้นการตัดสินใจทางสถาปัตยกรรมอาจเป็นการตัดสินใจที่จะรวมระบบผ่านการส่งข้อความมากกว่า RPC (ดังนั้นจึงเป็นหลักการทั่วไปที่สามารถนำไปใช้ในหลายสถานที่และมีวัตถุประสงค์เพื่อนำไปใช้กับระบบทั้งหมด) การตัดสินใจออกแบบอาจใช้ต้นแบบ / thread thread structure ในโมดูลการจัดการคำร้องขออินพุตของระบบ (หลักการทั่วไปที่สามารถใช้ได้ทุกที่ แต่ในกรณีนี้ใช้เพียงหนึ่งโมดูล) และในที่สุดการตัดสินใจในการนำไปใช้อาจต้องย้ายความรับผิดชอบเพื่อความปลอดภัยจาก Request Router ไปยัง Request Handler ในโมดูล Request Manager (การตัดสินใจที่เกี่ยวข้องกับบริบทนั้นเท่านั้นที่ใช้ในบริบทนั้น)

ฉันหวังว่านี่จะช่วยได้!