คู่มือฉบับย่อ

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

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

สถาปัตยกรรมซอฟต์แวร์

สถาปัตยกรรมทำหน้าที่เป็น blueprint for a system. มันเป็นสิ่งที่เป็นนามธรรมในการจัดการความซับซ้อนของระบบและสร้างกลไกการสื่อสารและการประสานงานระหว่างส่วนประกอบต่างๆ

  • เป็นการกำหนด structured solution เพื่อให้เป็นไปตามข้อกำหนดทางเทคนิคและการปฏิบัติงานทั้งหมดในขณะที่เพิ่มประสิทธิภาพคุณสมบัติคุณภาพทั่วไปเช่นประสิทธิภาพและความปลอดภัย

  • นอกจากนี้ยังเกี่ยวข้องกับชุดของการตัดสินใจที่สำคัญเกี่ยวกับองค์กรที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์และการตัดสินใจแต่ละอย่างอาจส่งผลกระทบอย่างมากต่อคุณภาพการบำรุงรักษาประสิทธิภาพและความสำเร็จโดยรวมของผลิตภัณฑ์ขั้นสุดท้าย การตัดสินใจเหล่านี้ประกอบด้วย -

    • การเลือกองค์ประกอบโครงสร้างและส่วนต่อประสานที่ระบบประกอบด้วย

    • พฤติกรรมตามที่ระบุไว้ในความร่วมมือระหว่างองค์ประกอบเหล่านั้น

    • การจัดองค์ประกอบโครงสร้างและพฤติกรรมเหล่านี้ให้เป็นระบบย่อยขนาดใหญ่

    • การตัดสินใจทางสถาปัตยกรรมสอดคล้องกับวัตถุประสงค์ทางธุรกิจ

    • รูปแบบสถาปัตยกรรมเป็นแนวทางในองค์กร

การออกแบบซอฟต์แวร์

การออกแบบซอฟต์แวร์ให้ไฟล์ design planที่อธิบายองค์ประกอบของระบบความเหมาะสมและทำงานร่วมกันเพื่อตอบสนองความต้องการของระบบ วัตถุประสงค์ของการวางแผนการออกแบบมีดังนี้ -

  • เพื่อเจรจาความต้องการของระบบและกำหนดความคาดหวังกับลูกค้าการตลาดและบุคลากรด้านการจัดการ

  • ทำหน้าที่เป็นพิมพ์เขียวในระหว่างกระบวนการพัฒนา

  • เป็นแนวทางในการดำเนินงานรวมถึงการออกแบบโดยละเอียดการเข้ารหัสการรวมและการทดสอบ

มาก่อนการออกแบบรายละเอียดการเข้ารหัสการรวมและการทดสอบและหลังจากการวิเคราะห์โดเมนการวิเคราะห์ข้อกำหนดและการวิเคราะห์ความเสี่ยง

เป้าหมายของสถาปัตยกรรม

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

เป้าหมายอื่น ๆ มีดังนี้ -

  • เปิดเผยโครงสร้างของระบบ แต่ซ่อนรายละเอียดการใช้งาน

  • ตระหนักถึงกรณีการใช้งานและสถานการณ์ทั้งหมด

  • พยายามตอบสนองความต้องการของผู้มีส่วนได้ส่วนเสียต่างๆ

  • จัดการทั้งความต้องการด้านการใช้งานและคุณภาพ

  • ลดเป้าหมายในการเป็นเจ้าของและปรับปรุงตำแหน่งทางการตลาดขององค์กร

  • ปรับปรุงคุณภาพและฟังก์ชันการทำงานที่ระบบนำเสนอ

  • ปรับปรุงความเชื่อมั่นภายนอกในองค์กรหรือระบบ

ข้อ จำกัด

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

  • ขาดเครื่องมือและวิธีการที่เป็นมาตรฐานในการแสดงสถาปัตยกรรม

  • ขาดวิธีการวิเคราะห์เพื่อทำนายว่าสถาปัตยกรรมจะทำให้เกิดการนำไปใช้งานที่ตรงตามข้อกำหนดหรือไม่

  • ขาดความตระหนักถึงความสำคัญของการออกแบบสถาปัตยกรรมต่อการพัฒนาซอฟต์แวร์

  • ขาดความเข้าใจในบทบาทของสถาปนิกซอฟต์แวร์และการสื่อสารที่ไม่ดีระหว่างผู้มีส่วนได้ส่วนเสีย

  • ขาดความเข้าใจในกระบวนการออกแบบประสบการณ์การออกแบบและการประเมินการออกแบบ

บทบาทของสถาปนิกซอฟต์แวร์

Software Architect มีโซลูชันที่ทีมเทคนิคสามารถสร้างและออกแบบสำหรับแอปพลิเคชันทั้งหมด สถาปนิกซอฟต์แวร์ควรมีความเชี่ยวชาญในด้านต่อไปนี้ -

ความเชี่ยวชาญด้านการออกแบบ

  • ผู้เชี่ยวชาญด้านการออกแบบซอฟต์แวร์รวมถึงวิธีการและแนวทางที่หลากหลายเช่นการออกแบบเชิงวัตถุการออกแบบที่ขับเคลื่อนด้วยเหตุการณ์เป็นต้น

  • นำทีมพัฒนาและประสานงานความพยายามในการพัฒนาเพื่อความสมบูรณ์ของการออกแบบ

  • ควรจะตรวจสอบข้อเสนอการออกแบบและแลกเปลี่ยนกันเองได้

ความเชี่ยวชาญด้านโดเมน

  • ผู้เชี่ยวชาญในระบบที่กำลังพัฒนาและวางแผนสำหรับวิวัฒนาการซอฟต์แวร์

  • ช่วยในกระบวนการตรวจสอบข้อกำหนดเพื่อให้มั่นใจว่ามีความครบถ้วนและสม่ำเสมอ

  • ประสานความหมายของแบบจำลองโดเมนสำหรับระบบที่กำลังพัฒนา

ความเชี่ยวชาญด้านเทคโนโลยี

  • ผู้เชี่ยวชาญเกี่ยวกับเทคโนโลยีที่มีอยู่ซึ่งช่วยในการนำระบบไปใช้งาน

  • ประสานงานการเลือกภาษาการเขียนโปรแกรมเฟรมเวิร์กแพลตฟอร์มฐานข้อมูล ฯลฯ

ความเชี่ยวชาญด้านระเบียบวิธี

  • ผู้เชี่ยวชาญเกี่ยวกับวิธีการพัฒนาซอฟต์แวร์ที่อาจนำมาใช้ในระหว่าง SDLC (Software Development Life Cycle)

  • เลือกแนวทางที่เหมาะสมสำหรับการพัฒนาที่ช่วยทั้งทีม

บทบาทที่ซ่อนอยู่ของสถาปนิกซอฟต์แวร์

  • อำนวยความสะดวกในการทำงานด้านเทคนิคระหว่างสมาชิกในทีมและเสริมสร้างความสัมพันธ์ที่ไว้วางใจในทีม

  • ผู้เชี่ยวชาญด้านข้อมูลที่แบ่งปันความรู้และมีประสบการณ์มากมาย

  • ปกป้องสมาชิกในทีมจากแรงภายนอกที่จะทำให้พวกเขาเสียสมาธิและสร้างมูลค่าให้กับโครงการน้อยลง

สิ่งที่ส่งมอบของสถาปนิก

  • ชุดเป้าหมายการทำงานที่ชัดเจนสมบูรณ์สอดคล้องและทำได้

  • คำอธิบายการทำงานของระบบที่มีการสลายตัวอย่างน้อยสองชั้น

  • แนวคิดสำหรับระบบ

  • การออกแบบในรูปแบบของระบบที่มีการสลายตัวอย่างน้อยสองชั้น

  • ความคิดเกี่ยวกับเวลาคุณลักษณะของตัวดำเนินการและการนำไปใช้และแผนการดำเนินงาน

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

คุณสมบัติคุณภาพ

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

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

พวกเขาสามารถจัดเป็น -

คุณสมบัติคุณภาพคงที่

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

คุณสมบัติคุณภาพแบบไดนามิก

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

ผู้ใช้ปลายทางสามารถมองเห็นได้และมีอยู่ที่รันไทม์เช่นปริมาณงานความทนทานความสามารถในการปรับขนาด ฯลฯ

สถานการณ์คุณภาพ

สถานการณ์จำลองคุณภาพระบุวิธีป้องกันข้อบกพร่องไม่ให้กลายเป็นความล้มเหลว สามารถแบ่งออกเป็นหกส่วนตามข้อกำหนดคุณลักษณะ -

  • Source - หน่วยงานภายในหรือภายนอกเช่นคนฮาร์ดแวร์ซอฟต์แวร์หรือโครงสร้างพื้นฐานทางกายภาพที่สร้างสิ่งกระตุ้น

  • Stimulus - เงื่อนไขที่ต้องพิจารณาเมื่อมาถึงระบบ

  • Environment - สิ่งกระตุ้นเกิดขึ้นภายในเงื่อนไขบางประการ

  • Artifact - ทั้งระบบหรือบางส่วนเช่นโปรเซสเซอร์ช่องทางการสื่อสารหน่วยเก็บข้อมูลถาวรกระบวนการ ฯลฯ

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

  • Response measure - ควรวัดการตอบสนองที่เกิดขึ้นเพื่อให้สามารถทดสอบข้อกำหนดได้

คุณสมบัติคุณภาพทั่วไป

ตารางต่อไปนี้แสดงคุณสมบัติคุณภาพทั่วไปที่สถาปัตยกรรมซอฟต์แวร์ต้องมี -

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

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

รูปแบบสถาปัตยกรรม

architectural styleหรือเรียกอีกอย่างว่า architectural patternคือชุดของหลักการที่กำหนดรูปแบบแอปพลิเคชัน เป็นการกำหนดกรอบนามธรรมสำหรับครอบครัวของระบบในแง่ของรูปแบบของโครงสร้างองค์กร

รูปแบบสถาปัตยกรรมมีหน้าที่ -

  • ให้คำศัพท์เกี่ยวกับส่วนประกอบและตัวเชื่อมต่อพร้อมกฎว่าจะรวมกันได้อย่างไร

  • ปรับปรุงการแบ่งพาร์ติชันและอนุญาตให้นำการออกแบบกลับมาใช้ใหม่โดยให้แนวทางแก้ไขปัญหาที่เกิดขึ้นบ่อยครั้ง

  • อธิบายวิธีการกำหนดค่าชุดส่วนประกอบ (โมดูลที่มีอินเทอร์เฟซที่กำหนดไว้อย่างดีใช้ซ้ำได้และเปลี่ยนได้) และตัวเชื่อมต่อ (การเชื่อมโยงการสื่อสารระหว่างโมดูล)

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

  • ชุดของประเภทส่วนประกอบที่ทำหน้าที่ตามที่ระบบต้องการ

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

  • ข้อ จำกัด เชิงความหมายซึ่งกำหนดวิธีการรวมส่วนประกอบเพื่อสร้างระบบ

  • เค้าโครงทอพอโลยีของส่วนประกอบที่ระบุความสัมพันธ์ระหว่างรันไทม์

การออกแบบสถาปัตยกรรมทั่วไป

ตารางต่อไปนี้แสดงรูปแบบสถาปัตยกรรมที่สามารถจัดระเบียบตามพื้นที่โฟกัสหลัก -

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

ประเภทของสถาปัตยกรรม

มีสถาปัตยกรรมสี่ประเภทจากมุมมองขององค์กรและโดยรวมแล้วสถาปัตยกรรมเหล่านี้เรียกว่า enterprise architecture.

  • Business architecture - กำหนดกลยุทธ์ของธุรกิจการกำกับดูแลองค์กรและกระบวนการทางธุรกิจที่สำคัญภายในองค์กรและมุ่งเน้นไปที่การวิเคราะห์และออกแบบกระบวนการทางธุรกิจ

  • Application (software) architecture - ทำหน้าที่เป็นพิมพ์เขียวสำหรับระบบแอปพลิเคชันแต่ละระบบการโต้ตอบและความสัมพันธ์กับกระบวนการทางธุรกิจขององค์กร

  • Information architecture - กำหนดสินทรัพย์ข้อมูลเชิงตรรกะและทางกายภาพและทรัพยากรการจัดการข้อมูล

  • Information technology (IT) architecture - กำหนดโครงสร้างฮาร์ดแวร์และซอฟต์แวร์ที่ประกอบเป็นระบบข้อมูลโดยรวมขององค์กร

กระบวนการออกแบบสถาปัตยกรรม

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

  • ข้อกำหนดที่ผลิตโดยงานวิเคราะห์

  • สถาปัตยกรรมฮาร์ดแวร์ (สถาปนิกซอฟต์แวร์จะให้ข้อกำหนดแก่สถาปนิกระบบซึ่งเป็นผู้กำหนดค่าสถาปัตยกรรมฮาร์ดแวร์)

ผลลัพธ์หรือผลลัพธ์ของกระบวนการออกแบบสถาปัตยกรรมคือ architectural description. ขั้นตอนการออกแบบสถาปัตยกรรมพื้นฐานประกอบด้วยขั้นตอนต่อไปนี้ -

ทำความเข้าใจกับปัญหา

  • นี่เป็นขั้นตอนที่สำคัญที่สุดเนื่องจากมีผลต่อคุณภาพของการออกแบบที่ตามมา

  • หากไม่มีความเข้าใจที่ชัดเจนเกี่ยวกับปัญหาก็จะไม่สามารถสร้างวิธีแก้ปัญหาที่มีประสิทธิภาพได้

  • โครงการซอฟต์แวร์และผลิตภัณฑ์จำนวนมากถือว่าล้มเหลวเนื่องจากไม่ได้แก้ปัญหาทางธุรกิจที่ถูกต้องหรือมีผลตอบแทนจากการลงทุน (ROI) ที่เป็นที่รู้จัก

ระบุองค์ประกอบการออกแบบและความสัมพันธ์

  • ในขั้นตอนนี้สร้างพื้นฐานสำหรับการกำหนดขอบเขตและบริบทของระบบ

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

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

ประเมินการออกแบบสถาปัตยกรรม

  • แต่ละแอตทริบิวต์คุณภาพจะได้รับการประมาณดังนั้นเพื่อรวบรวมมาตรการเชิงคุณภาพหรือข้อมูลเชิงปริมาณการออกแบบจะได้รับการประเมิน

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

  • หากแอตทริบิวต์คุณภาพโดยประมาณทั้งหมดเป็นไปตามมาตรฐานที่กำหนดกระบวนการออกแบบสถาปัตยกรรมจะเสร็จสิ้น

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

พลิกโฉมการออกแบบสถาปัตยกรรม

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

  • เกี่ยวข้องกับการเลือกโซลูชันการออกแบบเพื่อปรับปรุงคุณลักษณะด้านคุณภาพในขณะที่รักษาการทำงานของโดเมน

  • การออกแบบเปลี่ยนแปลงโดยใช้ตัวดำเนินการออกแบบสไตล์หรือรูปแบบ สำหรับการเปลี่ยนแปลงให้ใช้การออกแบบที่มีอยู่และใช้ตัวดำเนินการออกแบบเช่นการย่อยสลายการจำลองแบบการบีบอัดสิ่งที่เป็นนามธรรมและการแบ่งปันทรัพยากร

  • การออกแบบจะได้รับการประเมินอีกครั้งและกระบวนการเดียวกันจะทำซ้ำหลาย ๆ ครั้งหากจำเป็นและแม้กระทั่งดำเนินการซ้ำ

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

หลักการสถาปัตยกรรมที่สำคัญ

ต่อไปนี้เป็นหลักการสำคัญที่ต้องพิจารณาในขณะออกแบบสถาปัตยกรรม -

สร้างเพื่อเปลี่ยนแปลงแทนที่จะสร้างเป็นสุดท้าย

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

ลดความเสี่ยงและโมเดลในการวิเคราะห์

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

ใช้โมเดลและการแสดงภาพเป็นเครื่องมือการสื่อสารและการทำงานร่วมกัน

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

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

ใช้วิธีการเพิ่มหน่วยและการทำซ้ำ

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

หลักการออกแบบที่สำคัญ

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

การแยกความกังวล

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

หลักการความรับผิดชอบเดียว

แต่ละโมดูลของระบบควรมีความรับผิดชอบเฉพาะอย่างหนึ่งซึ่งช่วยให้ผู้ใช้เข้าใจระบบได้อย่างชัดเจน นอกจากนี้ยังควรช่วยในการรวมส่วนประกอบกับส่วนประกอบอื่น ๆ

หลักการของความรู้น้อยที่สุด

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

ลดการออกแบบขนาดใหญ่ล่วงหน้า

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

อย่าทำซ้ำฟังก์ชันการทำงาน

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

ชอบองค์ประกอบมากกว่าการสืบทอดในขณะที่ใช้ฟังก์ชันการทำงานซ้ำ

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

ระบุส่วนประกอบและจัดกลุ่มใน Logical Layers

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

กำหนดโปรโตคอลการสื่อสารระหว่างเลเยอร์

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

กำหนดรูปแบบข้อมูลสำหรับเลเยอร์

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

ส่วนประกอบของบริการระบบควรเป็นนามธรรม

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

การออกแบบข้อยกเว้นและกลไกการจัดการข้อยกเว้น

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

หลักการตั้งชื่อ

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

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

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

สถาปัตยกรรมซอฟต์แวร์สามารถกำหนดได้หลายวิธี -

  • UML (Unified Modeling Language) - UML เป็นหนึ่งในโซลูชันเชิงวัตถุที่ใช้ในการสร้างแบบจำลองและการออกแบบซอฟต์แวร์

  • Architecture View Model (4+1 view model) - แบบจำลองมุมมองสถาปัตยกรรมแสดงถึงข้อกำหนดด้านการทำงานและไม่ใช้งานได้ของแอปพลิเคชันซอฟต์แวร์

  • ADL (Architecture Description Language) - ADL กำหนดสถาปัตยกรรมซอฟต์แวร์อย่างเป็นทางการและตามความหมาย

UML

UML ย่อมาจาก Unified Modeling Language เป็นภาษาภาพที่ใช้ในการสร้างพิมพ์เขียวซอฟต์แวร์ UML ถูกสร้างโดย Object Management Group (OMG) ร่างข้อกำหนด UML 1.0 ได้รับการเสนอต่อ OMG ในเดือนมกราคม 1997 โดยทำหน้าที่เป็นมาตรฐานสำหรับการวิเคราะห์ความต้องการซอฟต์แวร์และเอกสารการออกแบบซึ่งเป็นพื้นฐานสำหรับการพัฒนาซอฟต์แวร์

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

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

แผนภาพโครงสร้าง

แผนภาพโครงสร้างแสดงลักษณะคงที่ของระบบ ลักษณะคงที่เหล่านี้แสดงถึงส่วนต่างๆของแผนภาพซึ่งเป็นโครงสร้างหลักดังนั้นจึงมีเสถียรภาพ

ชิ้นส่วนคงที่เหล่านี้แสดงโดยคลาสอินเทอร์เฟซวัตถุส่วนประกอบและโหนด แผนภาพโครงสร้างแบ่งย่อยได้ดังนี้ -

  • แผนภาพคลาส
  • แผนภาพวัตถุ
  • แผนภาพส่วนประกอบ
  • แผนภาพการปรับใช้
  • แผนภาพแพ็คเกจ
  • โครงสร้างคอมโพสิต

ตารางต่อไปนี้ให้คำอธิบายสั้น ๆ ของไดอะแกรมเหล่านี้ -

ซีเนียร์ แผนภาพและคำอธิบาย
1

Class

แสดงถึงการวางแนววัตถุของระบบ แสดงให้เห็นว่าคลาสมีความสัมพันธ์กันอย่างไร
2

Object

แสดงถึงชุดของอ็อบเจ็กต์และความสัมพันธ์ที่รันไทม์และยังแสดงถึงมุมมองแบบคงที่ของระบบ
3

Component

อธิบายส่วนประกอบทั้งหมดความสัมพันธ์ระหว่างกันปฏิสัมพันธ์และส่วนต่อประสานของระบบ
4

Composite structure

อธิบายโครงสร้างภายในของส่วนประกอบรวมถึงคลาสทั้งหมดส่วนต่อประสานของส่วนประกอบ ฯลฯ
5

Package

อธิบายโครงสร้างแพ็คเกจและองค์กร ครอบคลุมคลาสในแพ็คเกจและแพ็คเกจภายในแพ็คเกจอื่น
6

Deployment

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

แผนภาพพฤติกรรม

แผนภาพพฤติกรรมโดยพื้นฐานแล้วจะจับภาพลักษณะไดนามิกของระบบ แง่มุมแบบไดนามิกโดยพื้นฐานแล้วเป็นส่วนที่เปลี่ยนแปลง / เคลื่อนไหวของระบบ UML มีแผนภาพพฤติกรรมประเภทต่อไปนี้ -

  • ใช้แผนภาพกรณี
  • แผนภาพลำดับ
  • แผนภาพการสื่อสาร
  • แผนภาพแผนภูมิของรัฐ
  • แผนภาพกิจกรรม
  • ภาพรวมการโต้ตอบ
  • แผนภาพลำดับเวลา

ตารางต่อไปนี้ให้คำอธิบายสั้น ๆ ของแผนภาพเหล่านี้ -

ซีเนียร์ แผนภาพและคำอธิบาย
1

Use case

อธิบายความสัมพันธ์ระหว่างฟังก์ชันการทำงานและตัวควบคุมภายใน / ภายนอก ตัวควบคุมเหล่านี้เรียกได้ว่าเป็นนักแสดง
2

Activity

อธิบายขั้นตอนการควบคุมในระบบ ประกอบด้วยกิจกรรมและการเชื่อมโยง โฟลว์อาจเป็นแบบลำดับพร้อมกันหรือแยกกลุ่มก็ได้
3

State Machine/state chart

แสดงถึงการเปลี่ยนแปลงสถานะของระบบที่ขับเคลื่อนด้วยเหตุการณ์ โดยพื้นฐานแล้วจะอธิบายถึงการเปลี่ยนแปลงสถานะของคลาสอินเทอร์เฟซ ฯลฯ ใช้เพื่อแสดงภาพปฏิกิริยาของระบบโดยปัจจัยภายใน / ภายนอก
4

Sequence

แสดงภาพลำดับการโทรในระบบเพื่อดำเนินการทำงานเฉพาะ
5

Interaction Overview

รวมแผนภาพกิจกรรมและลำดับเพื่อให้ภาพรวมขั้นตอนการควบคุมของระบบและกระบวนการทางธุรกิจ
6

Communication

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

Time Sequenced

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

แบบจำลองมุมมองสถาปัตยกรรม

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

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

4 + 1 ดูโมเดล

แบบจำลองมุมมอง 4 + 1 ได้รับการออกแบบโดย Philippe Kruchten เพื่ออธิบายสถาปัตยกรรมของระบบที่ใช้ซอฟต์แวร์มากโดยอาศัยการใช้มุมมองที่หลากหลายและพร้อมกัน มันคือmultiple viewแบบจำลองที่เน้นคุณสมบัติและข้อกังวลต่างๆของระบบ เป็นมาตรฐานของเอกสารการออกแบบซอฟต์แวร์และทำให้ผู้มีส่วนได้ส่วนเสียทั้งหมดเข้าใจการออกแบบได้ง่าย

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

  • The logical view or conceptual view - อธิบายรูปแบบวัตถุของการออกแบบ

  • The process view - อธิบายกิจกรรมของระบบจับภาพการทำงานพร้อมกันและการซิงโครไนซ์ของการออกแบบ

  • The physical view - อธิบายถึงการทำแผนที่ซอฟต์แวร์กับฮาร์ดแวร์และสะท้อนถึงแง่มุมที่กระจายออกไป

  • The development view - อธิบายองค์กรแบบคงที่หรือโครงสร้างของซอฟต์แวร์ในการพัฒนาสภาพแวดล้อม

โมเดลมุมมองนี้สามารถขยายได้โดยเพิ่มอีกหนึ่งมุมมองที่เรียกว่า scenario view หรือ use case viewสำหรับผู้ใช้ปลายทางหรือลูกค้าของระบบซอฟต์แวร์ มีความสอดคล้องกับมุมมองอื่น ๆ อีกสี่มุมมองและใช้เพื่อแสดงสถาปัตยกรรมที่ทำหน้าที่เป็นมุมมอง "บวกหนึ่ง", (4 + 1) มุมมอง รูปต่อไปนี้อธิบายสถาปัตยกรรมซอฟต์แวร์โดยใช้โมเดลมุมมองพร้อมกันห้ามุมมอง (4 + 1)

ทำไมถึงเรียกว่า 4 + 1 แทนที่จะเป็น 5?

use case viewมีความสำคัญเป็นพิเศษเนื่องจากมีรายละเอียดความต้องการระดับสูงของระบบในขณะที่มุมมองอื่น ๆ ให้รายละเอียดว่าข้อกำหนดเหล่านั้นรับรู้ได้อย่างไร เมื่อมุมมองอื่น ๆ ทั้งสี่มุมมองเสร็จสมบูรณ์มันซ้ำซ้อนอย่างมีประสิทธิภาพ อย่างไรก็ตามมุมมองอื่น ๆ ทั้งหมดจะเป็นไปไม่ได้หากไม่มี ภาพและตารางต่อไปนี้แสดงมุมมอง 4 + 1 โดยละเอียด -

ตรรกะ กระบวนการ การพัฒนา ทางกายภาพ สถานการณ์
คำอธิบาย แสดงส่วนประกอบ (Object) ของระบบตลอดจนปฏิสัมพันธ์ แสดงกระบวนการ / กฎเวิร์กโฟลว์ของระบบและวิธีการสื่อสารของกระบวนการโดยเน้นที่มุมมองแบบไดนามิกของระบบ ให้มุมมอง Building Block ของระบบและอธิบายการจัดระเบียบแบบคงที่ของโมดูลระบบ แสดงการติดตั้งการกำหนดค่าและการปรับใช้แอปพลิเคชันซอฟต์แวร์ แสดงให้เห็นว่าการออกแบบเสร็จสมบูรณ์โดยดำเนินการตรวจสอบความถูกต้องและภาพประกอบ
ผู้ดู / ผู้ถือหุ้น ผู้ใช้ปลายทางนักวิเคราะห์และนักออกแบบ ผู้รวมและนักพัฒนา โปรแกรมเมอร์และผู้จัดการโครงการซอฟต์แวร์ วิศวกรระบบผู้ปฏิบัติงานผู้ดูแลระบบและผู้ติดตั้งระบบ มุมมองของมุมมองและผู้ประเมินทั้งหมด
พิจารณา ความต้องการการทำงาน ข้อกำหนดที่ไม่ใช่หน้าที่ องค์กรโมดูลซอฟต์แวร์ (การใช้การจัดการซอฟต์แวร์ซ้ำข้อ จำกัด ของเครื่องมือ) ข้อกำหนดที่ไม่สามารถใช้งานได้เกี่ยวกับฮาร์ดแวร์พื้นฐาน ความสอดคล้องและความถูกต้องของระบบ
UML - แผนภาพ คลาสสถานะวัตถุลำดับแผนภาพการสื่อสาร แผนภาพกิจกรรม ส่วนประกอบแผนภาพแพ็คเกจ แผนภาพการปรับใช้ ใช้แผนภาพกรณี

ภาษาคำอธิบายสถาปัตยกรรม (ADL)

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

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

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

ยากที่จะจำแนกหรือแยกความแตกต่างของ ADL และภาษาโปรแกรมหรือภาษาโมเดล อย่างไรก็ตามมีข้อกำหนดต่อไปนี้สำหรับภาษาที่จะจัดประเภทเป็น ADL -

  • ควรเป็นเรื่องที่เหมาะสมสำหรับการสื่อสารสถาปัตยกรรมกับทุกฝ่ายที่เกี่ยวข้อง

  • ควรเหมาะสำหรับงานสร้างสถาปัตยกรรมการปรับแต่งและการตรวจสอบความถูกต้อง

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

  • ควรมีความสามารถในการแสดงรูปแบบสถาปัตยกรรมทั่วไปส่วนใหญ่

  • ควรสนับสนุนความสามารถในการวิเคราะห์หรือจัดเตรียมการใช้งานต้นแบบอย่างรวดเร็ว

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

  • ภาษาเชิงวัตถุแรกคือ Simula (การจำลองระบบจริง) ที่ได้รับการพัฒนาขึ้นในปี พ.ศ. 2503 โดยนักวิจัยของศูนย์คอมพิวเตอร์แห่งนอร์เวย์

  • ในปีพ. ศ. 2513 Alan Kay และกลุ่มวิจัยของเขาที่ Xerox PARC ได้สร้างคอมพิวเตอร์ส่วนบุคคลชื่อ Dynabook และภาษาการเขียนโปรแกรมเชิงวัตถุบริสุทธิ์ตัวแรก (OOPL) - Smalltalk สำหรับการเขียนโปรแกรม Dynabook

  • ในช่วงทศวรรษที่ 1980 Grady Boochตีพิมพ์บทความชื่อ Object Oriented Design ที่นำเสนอการออกแบบสำหรับภาษาโปรแกรมเป็นหลัก Ada ในรุ่นต่อ ๆ มาเขาได้ขยายแนวคิดของเขาไปสู่วิธีการออกแบบเชิงวัตถุที่สมบูรณ์

  • ในช่วงปี 1990 Coad รวมแนวคิดเชิงพฤติกรรมเข้ากับวิธีการเชิงวัตถุ

นวัตกรรมที่สำคัญอื่น ๆ ได้แก่ Object Modeling Techniques (OMT) โดย James Rum Baugh และวิศวกรรมซอฟต์แวร์เชิงวัตถุ (OOSE) โดย Ivar Jacobson.

รู้เบื้องต้นเกี่ยวกับ OO Paradigm

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

แนวคิดและคำศัพท์พื้นฐานของระบบเชิงวัตถุ -

วัตถุ

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

  • เอกลักษณ์ที่แยกความแตกต่างจากวัตถุอื่น ๆ ในระบบ

  • สถานะที่กำหนดคุณสมบัติลักษณะของอ็อบเจ็กต์ตลอดจนค่าคุณสมบัติที่อ็อบเจ็กต์เก็บไว้

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

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

คลาส

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

องค์ประกอบของคลาสคือ -

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

  • ชุดของการดำเนินการที่แสดงให้เห็นพฤติกรรมของออบเจ็กต์ของคลาส การดำเนินการเรียกอีกอย่างว่าฟังก์ชันหรือวิธีการ

Example

ให้เราพิจารณาคลาสง่ายๆ Circle ที่แสดงถึงวงกลมรูปเรขาคณิตในปริภูมิสองมิติ คุณสมบัติของคลาสนี้สามารถระบุได้ดังนี้ -

  • x - พิกัดเพื่อแสดงพิกัด x ของจุดศูนย์กลาง
  • y - พิกัดเพื่อแสดงพิกัด y ของศูนย์กลาง
  • a เพื่อแสดงรัศมีของวงกลม

การดำเนินการบางอย่างสามารถกำหนดได้ดังนี้ -

  • findArea () วิธีการคำนวณพื้นที่
  • findCircumference () วิธีคำนวณเส้นรอบวง
  • สเกล () วิธีการเพิ่มหรือลดรัศมี

การห่อหุ้ม

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

ความแตกต่าง

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

Example

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

Relationships

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

ข้อความผ่าน

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

องค์ประกอบหรือการรวม

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

สมาคม

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

  • ความสัมพันธ์แบบยูนารีเชื่อมต่อออบเจ็กต์ของคลาสเดียวกัน
  • ความสัมพันธ์แบบไบนารีเชื่อมต่อออบเจ็กต์ของสองคลาส
  • ความสัมพันธ์แบบ ternary เชื่อมต่อออบเจ็กต์ที่มีตั้งแต่สามคลาสขึ้นไป

มรดก

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

คลาสย่อยสามารถสืบทอดหรือรับคุณสมบัติและวิธีการของ super-class ได้โดยที่ super-class อนุญาต นอกจากนี้คลาสย่อยอาจเพิ่มแอตทริบิวต์และวิธีการของตนเองและอาจปรับเปลี่ยนวิธีการระดับสูง การถ่ายทอดทางพันธุกรรมกำหนดความสัมพันธ์“ คือ - a”

Example

จากสัตว์เลี้ยงลูกด้วยนมระดับชั้นสามารถได้มาหลายคลาสเช่นมนุษย์แมวสุนัขวัว ฯลฯ มนุษย์แมวสุนัขและวัวล้วนมีลักษณะที่แตกต่างกันของสัตว์เลี้ยงลูกด้วยนม นอกจากนี้แต่ละคนมีลักษณะเฉพาะของตัวเอง อาจกล่าวได้ว่าวัว“ เป็น -” สัตว์เลี้ยงลูกด้วยนม

การวิเคราะห์ OO

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

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

การสร้างแบบจำลองวัตถุ

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

กระบวนการสร้างแบบจำลองวัตถุสามารถมองเห็นได้ในขั้นตอนต่อไปนี้ -

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

การสร้างแบบจำลองแบบไดนามิก

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

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

กระบวนการสร้างแบบจำลองแบบไดนามิกสามารถมองเห็นได้ในขั้นตอนต่อไปนี้ -

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

การสร้างแบบจำลองการทำงาน

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

กระบวนการสร้างแบบจำลองการทำงานสามารถมองเห็นได้ในขั้นตอนต่อไปนี้ -

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

การออกแบบเชิงวัตถุ

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

ขั้นตอนสำหรับการออกแบบเชิงวัตถุสามารถระบุได้ว่า -

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

การออกแบบ OO สามารถแบ่งออกเป็นสองขั้นตอน - การออกแบบแนวคิดและการออกแบบรายละเอียด

Conceptual design

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

Detailed design

ในขั้นตอนนี้คุณลักษณะและการดำเนินการจะถูกกำหนดให้กับแต่ละชั้นเรียนตามแผนภาพปฏิสัมพันธ์ แผนภาพเครื่องสถานะได้รับการพัฒนาเพื่ออธิบายรายละเอียดเพิ่มเติมของการออกแบบ เป็นที่รู้จักกันในชื่อlow-level design.

หลักการออกแบบ

หลักการออกแบบที่สำคัญมีดังต่อไปนี้ -

Principle of Decoupling

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

Ensuring Cohesion

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

Open-closed Principle

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

  • สำหรับแต่ละคลาสคอนกรีตจะต้องมีการบำรุงรักษาอินเตอร์เฟสและการใช้งานแยกกัน

  • ในสภาพแวดล้อมแบบมัลติเธรดเก็บแอตทริบิวต์ไว้เป็นส่วนตัว

  • ลดการใช้ตัวแปรส่วนกลางและตัวแปรคลาสให้น้อยที่สุด

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

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

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

  • ลำดับแบทช์
  • ท่อและตัวกรองหรือโหมดท่อส่งแบบไม่ต่อเนื่อง
  • การควบคุมกระบวนการ

ลำดับแบทช์

Batch sequential เป็นรูปแบบการประมวลผลข้อมูลแบบคลาสสิกซึ่งระบบย่อยการแปลงข้อมูลสามารถเริ่มต้นกระบวนการได้หลังจากที่ระบบย่อยก่อนหน้าผ่าน -

  • การไหลของข้อมูลมีชุดข้อมูลโดยรวมจากระบบย่อยหนึ่งไปยังอีกระบบหนึ่ง

  • การสื่อสารระหว่างโมดูลดำเนินการผ่านไฟล์กลางชั่วคราวซึ่งสามารถลบออกได้โดยระบบย่อยที่ต่อเนื่องกัน

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

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

ข้อดี

  • จัดเตรียมการหารที่ง่ายกว่าบนระบบย่อย

  • ระบบย่อยแต่ละระบบสามารถเป็นโปรแกรมอิสระที่ทำงานกับข้อมูลอินพุตและสร้างข้อมูลเอาต์พุต

ข้อเสีย

  • ให้เวลาแฝงสูงและปริมาณงานต่ำ

  • ไม่มีอินเทอร์เฟซแบบพร้อมกันและแบบโต้ตอบ

  • จำเป็นต้องมีการควบคุมภายนอกสำหรับการนำไปใช้งาน

สถาปัตยกรรมท่อและตัวกรอง

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

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

กรอง

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

Active filter

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

Passive filter

ตัวกรองแบบพาสซีฟช่วยให้ท่อที่เชื่อมต่อสามารถดันข้อมูลเข้าและดึงข้อมูลออกได้ ทำงานด้วยท่อที่ใช้งานอยู่ซึ่งดึงข้อมูลจากตัวกรองและส่งข้อมูลไปยังตัวกรองถัดไป ต้องมีกลไกการอ่าน / เขียน

ข้อดี

  • ให้การทำงานพร้อมกันและปริมาณงานสูงสำหรับการประมวลผลข้อมูลที่มากเกินไป

  • ให้การใช้ซ้ำและลดความยุ่งยากในการบำรุงรักษาระบบ

  • ให้ความสามารถในการปรับเปลี่ยนและการมีเพศสัมพันธ์ต่ำระหว่างตัวกรอง

  • ให้ความเรียบง่ายด้วยการแบ่งส่วนที่ชัดเจนระหว่างตัวกรองสองตัวที่เชื่อมต่อด้วยท่อ

  • ให้ความยืดหยุ่นโดยรองรับทั้งการดำเนินการตามลำดับและแบบขนาน

ข้อเสีย

  • ไม่เหมาะสำหรับการโต้ตอบแบบไดนามิก

  • จำเป็นต้องมีตัวส่วนร่วมต่ำสำหรับการส่งข้อมูลในรูปแบบ ASCII

  • ค่าใช้จ่ายในการแปลงข้อมูลระหว่างตัวกรอง

  • ไม่มีวิธีสำหรับตัวกรองในการโต้ตอบแบบร่วมมือกันเพื่อแก้ปัญหา

  • ยากที่จะกำหนดค่าสถาปัตยกรรมนี้แบบไดนามิก

ท่อ

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

สถาปัตยกรรมการควบคุมกระบวนการ

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

ประเภทของระบบย่อย

สถาปัตยกรรมการควบคุมกระบวนการจะมี processing unit สำหรับการเปลี่ยนตัวแปรควบคุมกระบวนการและก controller unit สำหรับการคำนวณปริมาณการเปลี่ยนแปลง

ชุดควบคุมต้องมีองค์ประกอบดังต่อไปนี้ -

  • Controlled Variable- Controlled Variable ให้ค่าสำหรับระบบพื้นฐานและควรวัดโดยเซ็นเซอร์ ตัวอย่างเช่นความเร็วในระบบควบคุมความเร็วคงที่

  • Input Variable- วัดข้อมูลเข้าสู่กระบวนการ ตัวอย่างเช่นอุณหภูมิของอากาศไหลกลับในระบบควบคุมอุณหภูมิ

  • Manipulated Variable - Manipulated Variable value ถูกปรับหรือเปลี่ยนแปลงโดยคอนโทรลเลอร์

  • Process Definition - รวมถึงกลไกในการจัดการตัวแปรกระบวนการบางอย่าง

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

  • Set Point - เป็นค่าที่ต้องการสำหรับตัวแปรควบคุม

  • Control Algorithm - ใช้สำหรับการตัดสินใจว่าจะจัดการตัวแปรกระบวนการอย่างไร

พื้นที่การใช้งาน

สถาปัตยกรรมการควบคุมกระบวนการเหมาะสมในโดเมนต่อไปนี้ -

  • การออกแบบซอฟต์แวร์ระบบฝังตัวซึ่งระบบถูกจัดการโดยข้อมูลตัวแปรการควบคุมกระบวนการ

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

  • ใช้ได้กับระบบควบคุมความเร็วรถและระบบควบคุมอุณหภูมิอาคาร

  • ซอฟต์แวร์ระบบเรียลไทม์เพื่อควบคุมเบรกป้องกันล้อล็อกรถยนต์โรงไฟฟ้านิวเคลียร์ ฯลฯ

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

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

อีกตัวอย่างหนึ่งของสถาปัตยกรรมที่เน้นข้อมูลเป็นศูนย์กลางคือสถาปัตยกรรมเว็บที่มีสคีมาข้อมูลทั่วไป (เช่นโครงสร้างเมตาของเว็บ) และตามรูปแบบข้อมูลไฮเปอร์มีเดียและกระบวนการสื่อสารผ่านการใช้บริการข้อมูลบนเว็บที่ใช้ร่วมกัน

ประเภทของส่วนประกอบ

ส่วนประกอบมีสองประเภท -

  • ก central dataโครงสร้างหรือที่เก็บข้อมูลหรือที่เก็บข้อมูลซึ่งมีหน้าที่จัดเก็บข้อมูลถาวร แสดงถึงสถานะปัจจุบัน

  • ก data accessor หรือชุดส่วนประกอบอิสระที่ทำงานบนที่เก็บข้อมูลส่วนกลางทำการคำนวณและอาจนำผลลัพธ์กลับมา

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

  • รูปแบบสถาปัตยกรรมพื้นที่เก็บข้อมูล
  • สไตล์สถาปัตยกรรมกระดานดำ

รูปแบบสถาปัตยกรรมพื้นที่เก็บข้อมูล

ใน Repository Architecture Style ที่เก็บข้อมูลเป็นแบบพาสซีฟและไคลเอนต์ (ส่วนประกอบซอฟต์แวร์หรือเอเจนต์) ของที่เก็บข้อมูลแอ็คทีฟซึ่งควบคุมโฟลว์ตรรกะ ส่วนประกอบที่เข้าร่วมจะตรวจสอบที่เก็บข้อมูลเพื่อดูการเปลี่ยนแปลง

  • ไคลเอนต์ส่งคำร้องขอไปยังระบบเพื่อดำเนินการต่างๆ (เช่นแทรกข้อมูล)

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

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

  • แนวทางนี้ใช้กันอย่างแพร่หลายใน DBMS, ระบบข้อมูลไลบรารี, ที่เก็บอินเทอร์เฟซในสภาพแวดล้อม CORBA, คอมไพเลอร์และ CASE (วิศวกรรมซอฟต์แวร์โดยใช้คอมพิวเตอร์ช่วย)

ข้อดี

  • ให้คุณสมบัติความสมบูรณ์ของข้อมูลสำรองและกู้คืน

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

  • ลดค่าใช้จ่ายของข้อมูลชั่วคราวระหว่างส่วนประกอบซอฟต์แวร์

ข้อเสีย

  • มีความเสี่ยงที่จะเกิดความล้มเหลวและการจำลองข้อมูลหรือการทำซ้ำเป็นไปได้

  • การพึ่งพาระหว่างโครงสร้างข้อมูลของที่เก็บข้อมูลและเอเจนต์สูง

  • การเปลี่ยนแปลงโครงสร้างข้อมูลส่งผลกระทบต่อลูกค้าอย่างมาก

  • วิวัฒนาการของข้อมูลเป็นเรื่องยากและมีราคาแพง

  • ค่าใช้จ่ายในการย้ายข้อมูลบนเครือข่ายสำหรับข้อมูลแบบกระจาย

สไตล์สถาปัตยกรรมกระดานดำ

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

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

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

  • สถานะปัจจุบันของโซลูชันจะถูกเก็บไว้ในกระดานดำและการประมวลผลจะถูกเรียกใช้โดยสถานะของกระดานดำ

  • ระบบจะส่งการแจ้งเตือนที่เรียกว่า trigger และข้อมูลให้กับลูกค้าเมื่อเกิดการเปลี่ยนแปลงในข้อมูล

  • แนวทางนี้พบได้ในแอปพลิเคชัน AI และแอพพลิเคชั่นที่ซับซ้อนเช่นการรู้จำเสียงการจดจำภาพระบบรักษาความปลอดภัยและระบบการจัดการทรัพยากรทางธุรกิจเป็นต้น

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

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

ชิ้นส่วนของโมเดลกระดานดำ

แบบจำลองกระดานดำมักจะนำเสนอด้วยสามส่วนหลัก -

Knowledge Sources (KS)

แหล่งความรู้หรือที่เรียกว่า Listeners หรือ Subscribersเป็นหน่วยที่แตกต่างและเป็นอิสระ พวกเขาแก้ปัญหาบางส่วนและรวบรวมผลลัพธ์บางส่วน การโต้ตอบระหว่างแหล่งความรู้เกิดขึ้นโดยไม่ซ้ำกันผ่านกระดานดำ

Blackboard Data Structure

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

Control

ควบคุมจัดการงานและตรวจสอบสถานะการทำงาน

ข้อดี

  • ให้ความสามารถในการปรับขนาดซึ่งทำให้ง่ายต่อการเพิ่มหรืออัปเดตแหล่งความรู้

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

  • รองรับการทดลองสำหรับสมมติฐาน

  • รองรับการใช้ซ้ำของตัวแทนแหล่งความรู้

ข้อเสีย

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

  • อาจเป็นเรื่องยากที่จะตัดสินใจว่าจะยุติการให้เหตุผลเมื่อใดเนื่องจากคาดว่าจะมีเพียงวิธีแก้ปัญหาโดยประมาณเท่านั้น

  • ปัญหาในการซิงโครไนซ์ของหลายตัวแทน

  • ความท้าทายที่สำคัญในการออกแบบและทดสอบระบบ

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

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

นอกจากนี้ยังใช้ในการจัดระเบียบไลบรารีคลาสเช่นไลบรารีคลาส. NET ในลำดับชั้นเนมสเปซ การออกแบบทุกประเภทสามารถใช้สถาปัตยกรรมลำดับชั้นนี้และมักจะรวมกับรูปแบบสถาปัตยกรรมอื่น ๆ

รูปแบบสถาปัตยกรรมตามลำดับชั้นแบ่งออกเป็น -

  • Main-subroutine
  • Master-slave
  • เครื่องเสมือน

รูทีนย่อยหลัก

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

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

มีสองวิธีในการส่งผ่านข้อมูลเป็นพารามิเตอร์ไปยังรูทีนย่อย ได้แก่ -

  • Pass by Value - รูทีนย่อยใช้เฉพาะข้อมูลในอดีต แต่ไม่สามารถแก้ไขได้

  • Pass by Reference - รูทีนย่อยใช้เช่นเดียวกับการเปลี่ยนแปลงค่าของข้อมูลที่อ้างอิงโดยพารามิเตอร์

ข้อดี

  • ง่ายต่อการย่อยสลายระบบตามการปรับแต่งลำดับชั้น

  • สามารถใช้ในระบบย่อยของการออกแบบเชิงวัตถุ

ข้อเสีย

  • มีช่องโหว่เนื่องจากมีข้อมูลที่แชร์ทั่วโลก

  • การมีเพศสัมพันธ์อย่างแน่นหนาอาจทำให้เกิดการกระเพื่อมของการเปลี่ยนแปลงมากขึ้น

มาสเตอร์ - ทาส

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

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

การใช้รูปแบบ Master-Slave เป็นไปตามห้าขั้นตอน -

  • ระบุวิธีการคำนวณของงานที่สามารถแบ่งออกเป็นชุดของงานย่อยที่เท่ากันและระบุบริการย่อยที่จำเป็นในการประมวลผลงานย่อย

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

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

  • ใช้ส่วนประกอบ Slave ตามข้อกำหนดที่พัฒนาในขั้นตอนก่อนหน้า

  • ใช้งานต้นแบบตามข้อกำหนดที่พัฒนาในขั้นตอนที่ 1 ถึง 3

การใช้งาน

  • เหมาะสำหรับการใช้งานที่ความน่าเชื่อถือของซอฟต์แวร์เป็นปัญหาสำคัญ

  • ใช้กันอย่างแพร่หลายในด้านการคำนวณแบบขนานและแบบกระจาย

ข้อดี

  • คำนวณได้เร็วขึ้นและปรับขนาดได้ง่าย

  • ให้ความแข็งแกร่งเนื่องจากทาสสามารถทำซ้ำได้

  • Slave สามารถใช้งานได้แตกต่างกันเพื่อลดข้อผิดพลาดทางความหมาย

ข้อเสีย

  • ค่าใช้จ่ายในการสื่อสาร

  • ปัญหาทั้งหมดไม่สามารถแบ่งออกได้

  • ใช้งานยากและปัญหาการพกพา

สถาปัตยกรรมเครื่องเสมือน

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

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

ในกรณีส่วนใหญ่เครื่องเสมือนจะแยกภาษาโปรแกรมหรือสภาพแวดล้อมของแอปพลิเคชันออกจากแพลตฟอร์มการดำเนินการ วัตถุประสงค์หลักคือการให้portability. การตีความโมดูลเฉพาะผ่านเครื่องเสมือนอาจถูกมองว่า -

  • เอ็นจินการตีความจะเลือกคำสั่งจากโมดูลที่กำลังตีความ

  • ตามคำสั่งเครื่องยนต์จะอัปเดตสถานะภายในของเครื่องเสมือนและกระบวนการข้างต้นจะทำซ้ำ

รูปต่อไปนี้แสดงสถาปัตยกรรมของโครงสร้างพื้นฐาน VM มาตรฐานบนเครื่องจริงเครื่องเดียว

hypervisor, เรียกอีกอย่างว่า virtual machine monitorรันบนโฮสต์ OS และจัดสรรทรัพยากรที่ตรงกันให้กับระบบปฏิบัติการของแขกแต่ละคน เมื่อแขกทำการโทรระบบไฮเปอร์ไวเซอร์จะสกัดกั้นและแปลเป็นการเรียกระบบที่สอดคล้องกันที่โฮสต์ OS สนับสนุน ไฮเปอร์ไวเซอร์ควบคุมการเข้าถึงเครื่องเสมือนแต่ละเครื่องไปยัง CPU หน่วยความจำหน่วยเก็บข้อมูลถาวรอุปกรณ์ I / O และเครือข่าย

การใช้งาน

สถาปัตยกรรมเครื่องเสมือนเหมาะในโดเมนต่อไปนี้ -

  • เหมาะสำหรับการแก้ปัญหาโดยการจำลองหรือการแปลหากไม่มีวิธีแก้ปัญหาโดยตรง

  • แอปพลิเคชันตัวอย่าง ได้แก่ ล่ามของไมโครโปรแกรมการประมวลผล XML การเรียกใช้ภาษาคำสั่งสคริปต์การเรียกใช้ระบบตามกฎ Smalltalk และ Java ล่ามภาษาการเขียนโปรแกรมที่พิมพ์

  • ตัวอย่างทั่วไปของเครื่องเสมือน ได้แก่ ตัวแปลภาษาระบบอิงกฎไวยากรณ์เชลล์และตัวประมวลผลภาษาคำสั่ง

ข้อดี

  • ความเป็นอิสระในการพกพาและแพลตฟอร์มเครื่องจักร

  • ความเรียบง่ายของการพัฒนาซอฟต์แวร์

  • ให้ความยืดหยุ่นผ่านความสามารถในการขัดจังหวะและสอบถามโปรแกรม

  • การจำลองแบบจำลองการทำงานในภัยพิบัติ

  • แนะนำการปรับเปลี่ยนที่รันไทม์

ข้อเสีย

  • การดำเนินการของล่ามช้าเนื่องจากลักษณะของล่าม

  • มีต้นทุนประสิทธิภาพเนื่องจากการคำนวณเพิ่มเติมที่เกี่ยวข้องกับการดำเนินการ

สไตล์ชั้น

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

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

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

การใช้งาน

สไตล์ชั้นเหมาะสำหรับพื้นที่ต่อไปนี้ -

  • แอปพลิเคชันที่เกี่ยวข้องกับคลาสของบริการที่แตกต่างกันซึ่งสามารถจัดระเบียบตามลำดับชั้น

  • แอปพลิเคชันใด ๆ ที่สามารถแยกย่อยออกเป็นส่วนเฉพาะแอปพลิเคชันและเฉพาะแพลตฟอร์ม

  • แอปพลิเคชันที่มีการแบ่งส่วนที่ชัดเจนระหว่างบริการหลักบริการสำคัญและบริการอินเทอร์เฟซผู้ใช้ ฯลฯ

ข้อดี

  • การออกแบบตามระดับที่เพิ่มขึ้นของนามธรรม

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

  • การแยกอินเทอร์เฟซมาตรฐานและการใช้งาน

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

  • แต่ละเลเยอร์สามารถเป็นเครื่องจักรนามธรรมที่ปรับใช้อย่างอิสระซึ่งรองรับการพกพา

  • ง่ายต่อการย่อยสลายระบบตามคำจำกัดความของงานในลักษณะการปรับแต่งจากบนลงล่าง

  • การใช้งานที่แตกต่างกัน (ที่มีอินเทอร์เฟซเหมือนกัน) ของเลเยอร์เดียวกันสามารถใช้แทนกันได้

ข้อเสีย

  • แอปพลิเคชันหรือระบบจำนวนมากไม่ได้มีโครงสร้างเป็นชั้น ๆ อย่างง่ายดาย

  • ประสิทธิภาพของรันไทม์ลดลงเนื่องจากคำขอของไคลเอ็นต์หรือการตอบกลับไปยังไคลเอนต์ต้องผ่านหลายชั้น

  • นอกจากนี้ยังมีข้อกังวลด้านประสิทธิภาพเกี่ยวกับค่าใช้จ่ายในการจัดเก็บข้อมูลและการบัฟเฟอร์ในแต่ละเลเยอร์

  • การเปิดการสื่อสารระหว่างชั้นอาจทำให้เกิดการหยุดชะงักและ "การเชื่อมต่อ" อาจทำให้เกิดการเชื่อมต่อที่แน่นหนา

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

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

  • Data module - โมดูลข้อมูลให้ข้อมูลที่เป็นนามธรรมและตรรกะทางธุรกิจทั้งหมด

  • Control module - โมดูลควบคุมระบุขั้นตอนของการควบคุมและการดำเนินการกำหนดค่าระบบ

  • View presentation module - โมดูลการนำเสนอมุมมองมีหน้าที่ในการนำเสนอภาพหรือเสียงของเอาต์พุตข้อมูลและยังมีอินเทอร์เฟซสำหรับการป้อนข้อมูลของผู้ใช้

สถาปัตยกรรมที่เน้นปฏิสัมพันธ์มีสองรูปแบบใหญ่ ๆ - Model-View-Controller (MVC) และ Presentation-Abstraction-Control(PAC). ทั้ง MVC และ PAC เสนอการสลายองค์ประกอบสามส่วนและใช้สำหรับแอปพลิเคชันแบบโต้ตอบเช่นเว็บแอปพลิเคชันที่มีการพูดคุยหลายครั้งและการโต้ตอบกับผู้ใช้ พวกเขามีความแตกต่างกันในขั้นตอนการควบคุมและองค์กร PAC เป็นสถาปัตยกรรมลำดับชั้นแบบเอเจนต์ แต่ MVC ไม่มีโครงสร้างลำดับชั้นที่ชัดเจน

รุ่นดูคอนโทรลเลอร์ (MVC)

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

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

รุ่น

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

  • เป็นอินเทอร์เฟซผู้ใช้ที่เป็นอิสระและจับพฤติกรรมของโดเมนปัญหาแอปพลิเคชัน

  • เป็นการจำลองซอฟต์แวร์เฉพาะโดเมนหรือการใช้โครงสร้างกลางของแอปพลิเคชัน

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

ดู

มุมมองสามารถใช้เพื่อแสดงผลลัพธ์ของข้อมูลในรูปแบบกราฟิกเช่นแผนภาพหรือแผนภูมิ ประกอบด้วยส่วนประกอบการนำเสนอที่ให้การแสดงข้อมูลด้วยภาพ

  • ดูข้อมูลร้องขอจากโมเดลของพวกเขาและสร้างการแสดงผลลัพธ์ให้กับผู้ใช้

  • สามารถดูข้อมูลเดียวกันได้หลายมุมมองเช่นแผนภูมิแท่งสำหรับการจัดการและมุมมองตารางสำหรับนักบัญชี

ตัวควบคุม

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

  • ทำหน้าที่เป็นอินเทอร์เฟซระหว่างโมเดลและมุมมองที่เกี่ยวข้องและอุปกรณ์อินพุต

  • สามารถส่งคำสั่งไปยังโมเดลเพื่ออัปเดตสถานะของโมเดลและไปยังมุมมองที่เกี่ยวข้องเพื่อเปลี่ยนมุมมองการนำเสนอของโมเดล

MVC - ฉัน

เป็นสถาปัตยกรรม MVC เวอร์ชันที่เรียบง่ายซึ่งระบบแบ่งออกเป็นสองระบบย่อย -

  • The Controller-View - มุมมองตัวควบคุมทำหน้าที่เป็นอินเทอร์เฟซอินพุต / เอาต์พุตและการประมวลผลเสร็จสิ้น

  • The Model - โมเดลให้บริการข้อมูลและโดเมนทั้งหมด

MVC-I Architecture

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

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

MVC - II

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

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

MVC-II Architecture

แอปพลิเคชั่น MVC

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

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

Advantages

  • มีชุดเครื่องมือเฟรมเวิร์กผู้ขาย MVC มากมาย

  • หลายมุมมองที่ซิงโครไนซ์กับโมเดลข้อมูลเดียวกัน

  • ง่ายต่อการเสียบใหม่หรือเปลี่ยนมุมมองอินเทอร์เฟซ

  • ใช้สำหรับการพัฒนาแอปพลิเคชันที่ผู้เชี่ยวชาญด้านกราฟิกผู้เชี่ยวชาญด้านการเขียนโปรแกรมและผู้เชี่ยวชาญด้านการพัฒนาฐานข้อมูลกำลังทำงานในทีมโครงการที่ออกแบบ

Disadvantages

  • ไม่เหมาะสำหรับแอปพลิเคชันที่มุ่งเน้นตัวแทนเช่นแอปพลิเคชันมือถือและหุ่นยนต์แบบโต้ตอบ

  • ตัวควบคุมและมุมมองหลายคู่ตามโมเดลข้อมูลเดียวกันทำให้โมเดลข้อมูลใด ๆ มีราคาแพง

  • การแบ่งระหว่าง View และ Controller ไม่ชัดเจนในบางกรณี

การนำเสนอ - นามธรรม - การควบคุม (PAC)

ใน PAC ระบบจะจัดเรียงเป็นลำดับชั้นของตัวแทนความร่วมมือจำนวนมาก (triads) ได้รับการพัฒนาจาก MVC เพื่อรองรับความต้องการใช้งานของตัวแทนหลายรายนอกเหนือจากข้อกำหนดแบบโต้ตอบ

ตัวแทนแต่ละคนมีสามองค์ประกอบ -

  • The presentation component - จัดรูปแบบการนำเสนอข้อมูลด้วยภาพและเสียง

  • The abstraction component - ดึงข้อมูลและประมวลผลข้อมูล

  • The control component - จัดการงานเช่นขั้นตอนการควบคุมและการสื่อสารระหว่างอีกสององค์ประกอบ

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

ไม่มีการเชื่อมต่อโดยตรงระหว่างองค์ประกอบนามธรรมและองค์ประกอบการนำเสนอในแต่ละตัวแทน ส่วนประกอบการควบคุมในแต่ละตัวแทนทำหน้าที่สื่อสารกับตัวแทนอื่น ๆ

รูปต่อไปนี้แสดงแผนภาพบล็อกสำหรับเอเจนต์เดียวในการออกแบบ PAC

PAC กับตัวแทนหลายคน

ใน PAC ประกอบด้วยหลายตัวแทนเอเจนต์ระดับบนสุดจะจัดเตรียมข้อมูลหลักและโลจิสติกส์ทางธุรกิจ ตัวแทนระดับล่างสุดจะกำหนดข้อมูลและการนำเสนอโดยละเอียด ตัวแทนระดับกลางหรือระดับกลางทำหน้าที่เป็นผู้ประสานงานของตัวแทนระดับต่ำ

  • ตัวแทนแต่ละคนมีงานที่ได้รับมอบหมายเฉพาะของตนเอง

  • สำหรับตัวแทนระดับกลางบางคนไม่จำเป็นต้องใช้การนำเสนอแบบโต้ตอบดังนั้นจึงไม่มีองค์ประกอบการนำเสนอ

  • ส่วนประกอบการควบคุมจำเป็นสำหรับเอเจนต์ทั้งหมดซึ่งตัวแทนทั้งหมดสื่อสารกัน

รูปต่อไปนี้แสดงตัวแทนหลายตัวที่มีส่วนร่วมใน PAC

Applications

  • มีผลสำหรับระบบโต้ตอบที่ระบบสามารถแยกย่อยออกเป็นเอเจนต์ความร่วมมือจำนวนมากในลักษณะตามลำดับชั้น

  • มีผลเมื่อคาดว่าการมีเพศสัมพันธ์ระหว่างตัวแทนจะหลวมเพื่อให้การเปลี่ยนแปลงในตัวแทนไม่ส่งผลกระทบต่อผู้อื่น

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

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

ข้อดี

  • รองรับการทำงานหลายอย่างและหลายการดู

  • รองรับการใช้ซ้ำของตัวแทนและความสามารถในการขยาย

  • ง่ายต่อการเสียบตัวแทนใหม่หรือเปลี่ยนตัวแทนที่มีอยู่

  • รองรับการทำงานพร้อมกันโดยที่เอเจนต์หลายตัวทำงานพร้อมกันในเธรดที่แตกต่างกันหรืออุปกรณ์หรือคอมพิวเตอร์ที่แตกต่างกัน

ข้อเสีย

  • ค่าใช้จ่ายเนื่องจากสะพานควบคุมระหว่างการนำเสนอและนามธรรมและการสื่อสารของการควบคุมระหว่างตัวแทน

  • ยากที่จะระบุจำนวนตัวแทนที่ถูกต้องเนื่องจากการมีเพศสัมพันธ์หลวมและมีความเป็นอิสระสูงระหว่างตัวแทน

  • การแยกการนำเสนอและนามธรรมอย่างสมบูรณ์โดยการควบคุมในแต่ละตัวแทนทำให้เกิดความซับซ้อนในการพัฒนาเนื่องจากการสื่อสารระหว่างตัวแทนจะเกิดขึ้นระหว่างการควบคุมของตัวแทนเท่านั้น

ในสถาปัตยกรรมแบบกระจายส่วนประกอบจะถูกนำเสนอบนแพลตฟอร์มที่แตกต่างกันและส่วนประกอบต่างๆสามารถทำงานร่วมกันผ่านเครือข่ายการสื่อสารเพื่อให้บรรลุวัตถุประสงค์หรือเป้าหมายที่เฉพาะเจาะจง

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

  • ระบบกระจายสามารถแสดงให้เห็นได้โดยสถาปัตยกรรมไคลเอนต์เซิร์ฟเวอร์ซึ่งเป็นฐานสำหรับสถาปัตยกรรมหลายชั้น ทางเลือกอื่นคือสถาปัตยกรรมนายหน้าเช่น CORBA และสถาปัตยกรรมเชิงบริการ (SOA)

  • มีเฟรมเวิร์กเทคโนโลยีหลายอย่างเพื่อสนับสนุนสถาปัตยกรรมแบบกระจาย ได้แก่ . NET, J2EE, CORBA, .NET Web services, AXIS Java Web services และ Globus Grid services

  • มิดเดิลแวร์เป็นโครงสร้างพื้นฐานที่รองรับการพัฒนาและการเรียกใช้แอปพลิเคชันแบบกระจายอย่างเหมาะสม มีบัฟเฟอร์ระหว่างแอปพลิเคชันและเครือข่าย

  • ตั้งอยู่ตรงกลางของระบบและจัดการหรือสนับสนุนส่วนประกอบต่างๆของระบบแบบกระจาย ตัวอย่าง ได้แก่ จอภาพการประมวลผลธุรกรรมตัวแปลงข้อมูลและตัวควบคุมการสื่อสารเป็นต้น

มิดเดิลแวร์เป็นโครงสร้างพื้นฐานสำหรับระบบกระจาย

พื้นฐานของสถาปัตยกรรมแบบกระจายคือความโปร่งใสความน่าเชื่อถือและความพร้อมใช้งาน

ตารางต่อไปนี้แสดงความโปร่งใสในรูปแบบต่างๆในระบบกระจาย -

ซีเนียร์ ความโปร่งใสและคำอธิบาย
1

Access

ซ่อนวิธีการเข้าถึงทรัพยากรและความแตกต่างในแพลตฟอร์มข้อมูล
2

Location

ซ่อนตำแหน่งของทรัพยากร
3

Technology

ซ่อนเทคโนโลยีต่างๆเช่นภาษาโปรแกรมและระบบปฏิบัติการจากผู้ใช้
4

Migration / Relocation

ซ่อนทรัพยากรที่อาจถูกย้ายไปยังตำแหน่งอื่นที่ใช้งานอยู่
5

Replication

ซ่อนทรัพยากรที่อาจถูกคัดลอกในหลายตำแหน่ง
6

Concurrency

ซ่อนทรัพยากรที่อาจแชร์กับผู้ใช้รายอื่น
7

Failure

ซ่อนความล้มเหลวและการกู้คืนทรัพยากรจากผู้ใช้
8

Persistence

ซ่อนว่าทรัพยากร (ซอฟต์แวร์) อยู่ในหน่วยความจำหรือดิสก์

ข้อดี

  • Resource sharing - การแบ่งปันทรัพยากรฮาร์ดแวร์และซอฟต์แวร์

  • Openness - ความยืดหยุ่นในการใช้ฮาร์ดแวร์และซอฟต์แวร์ของผู้ขายที่แตกต่างกัน

  • Concurrency - การประมวลผลพร้อมกันเพื่อเพิ่มประสิทธิภาพ

  • Scalability - เพิ่มปริมาณงานโดยการเพิ่มทรัพยากรใหม่

  • Fault tolerance - ความสามารถในการทำงานต่อไปหลังจากเกิดข้อผิดพลาด

ข้อเสีย

  • Complexity - มีความซับซ้อนมากกว่าระบบรวมศูนย์

  • Security - ไวต่อการโจมตีจากภายนอกมากขึ้น

  • Manageability - ต้องใช้ความพยายามมากขึ้นในการจัดการระบบ

  • Unpredictability - การตอบสนองที่คาดเดาไม่ได้ขึ้นอยู่กับองค์กรของระบบและภาระของเครือข่าย

ระบบส่วนกลางเทียบกับระบบกระจาย

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

สถาปัตยกรรมไคลเอนต์เซิร์ฟเวอร์

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

  • Client - นี่เป็นกระบวนการแรกที่ส่งคำขอไปยังกระบวนการที่สองคือเซิร์ฟเวอร์

  • Server - นี่เป็นกระบวนการที่สองที่รับคำขอดำเนินการและส่งคำตอบกลับไปยังลูกค้า

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

สถาปัตยกรรมไคลเอนต์เซิร์ฟเวอร์สามารถแบ่งออกเป็นสองรุ่นตามการทำงานของไคลเอนต์ -

รุ่น Thin-Client

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

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

  • ข้อเสียที่สำคัญคือทำให้เกิดภาระการประมวลผลที่หนักหน่วงทั้งบนเซิร์ฟเวอร์และเครือข่าย

รุ่นลูกค้าหนา / อ้วน

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

  • เหมาะสมที่สุดสำหรับระบบ C / S ใหม่ที่ทราบความสามารถของระบบไคลเอนต์ล่วงหน้า

  • ซับซ้อนกว่าแบบจำลองไคลเอ็นต์แบบบางโดยเฉพาะสำหรับการจัดการ ต้องติดตั้งแอปพลิเคชันเวอร์ชันใหม่บนไคลเอนต์ทั้งหมด

ข้อดี

  • การแยกความรับผิดชอบเช่นการนำเสนอส่วนติดต่อผู้ใช้และการประมวลผลตรรกะทางธุรกิจ

  • ความสามารถในการใช้ซ้ำของส่วนประกอบเซิร์ฟเวอร์และศักยภาพในการทำงานพร้อมกัน

  • ลดความยุ่งยากในการออกแบบและการพัฒนาแอปพลิเคชันแบบกระจาย

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

  • นอกจากนี้ยังใช้ทรัพยากรอย่างมีประสิทธิภาพเมื่อลูกค้าจำนวนมากเข้าถึงเซิร์ฟเวอร์ที่มีประสิทธิภาพสูง

ข้อเสีย

  • ขาดโครงสร้างพื้นฐานที่แตกต่างกันเพื่อรับมือกับการเปลี่ยนแปลงข้อกำหนด

  • ภาวะแทรกซ้อนด้านความปลอดภัย

  • ความพร้อมใช้งานของเซิร์ฟเวอร์ที่ จำกัด และความน่าเชื่อถือ

  • ความสามารถในการทดสอบและความยืดหยุ่นที่ จำกัด

  • ลูกค้าอ้วนด้วยการนำเสนอและตรรกะทางธุรกิจร่วมกัน

สถาปัตยกรรมหลายชั้น (สถาปัตยกรรม n-tier)

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

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

ระดับการนำเสนอ

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

ระดับแอปพลิเคชัน (Business Logic, Logic Tier หรือ Middle Tier)

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

ชั้นข้อมูล

ในเลเยอร์นี้ข้อมูลจะถูกจัดเก็บและเรียกใช้จากฐานข้อมูลหรือระบบไฟล์ จากนั้นข้อมูลจะถูกส่งกลับเพื่อประมวลผลและกลับไปยังผู้ใช้ ประกอบด้วยกลไกการคงอยู่ของข้อมูล (เซิร์ฟเวอร์ฐานข้อมูลการแชร์ไฟล์ ฯลฯ ) และจัดเตรียม API (Application Programming Interface) ให้กับระดับแอปพลิเคชันซึ่งมีวิธีการจัดการข้อมูลที่จัดเก็บไว้

Advantages

  • ประสิทธิภาพที่ดีกว่าวิธีการสำหรับลูกค้ารายย่อยและง่ายกว่าในการจัดการมากกว่าแนวทางลูกค้ารายใหญ่

  • ช่วยเพิ่มความสามารถในการนำกลับมาใช้ใหม่และความสามารถในการปรับขนาด - เมื่อความต้องการเพิ่มขึ้นสามารถเพิ่มเซิร์ฟเวอร์เพิ่มเติมได้

  • ให้การสนับสนุนมัลติเธรดและยังช่วยลดปริมาณการใช้งานเครือข่าย

  • ให้การบำรุงรักษาและความยืดหยุ่น

Disadvantages

  • ความสามารถในการทดสอบที่ไม่น่าพอใจเนื่องจากไม่มีเครื่องมือทดสอบ

  • ความน่าเชื่อถือและความพร้อมใช้งานของเซิร์ฟเวอร์ที่สำคัญยิ่งขึ้น

รูปแบบสถาปัตยกรรมนายหน้า

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

  • ไคลเอนต์และเซิร์ฟเวอร์ไม่โต้ตอบกันโดยตรง ไคลเอนต์และเซิร์ฟเวอร์มีการเชื่อมต่อโดยตรงกับพร็อกซีซึ่งสื่อสารกับโบรกเกอร์คนกลาง

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

  • CORBA (Common Object Request Broker Architecture) เป็นตัวอย่างการใช้งานที่ดีของสถาปัตยกรรมนายหน้า

ส่วนประกอบของรูปแบบสถาปัตยกรรมนายหน้า

ส่วนประกอบของรูปแบบสถาปัตยกรรมนายหน้าจะกล่าวถึงผ่านหัวต่อไปนี้ -

Broker

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

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

  • จะเก็บรักษาข้อมูลการลงทะเบียนของเซิร์ฟเวอร์รวมถึงฟังก์ชันการทำงานและบริการตลอดจนข้อมูลตำแหน่งที่ตั้ง

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

Stub

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

พร็อกซีจะซ่อน IPC (การสื่อสารระหว่างกระบวนการ) ที่ระดับโปรโตคอลและดำเนินการจัดเก็บค่าพารามิเตอร์และยกเลิกการจัดเก็บผลลัพธ์จากเซิร์ฟเวอร์

Skeleton

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

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

Bridge

บริดจ์สามารถเชื่อมต่อเครือข่ายสองเครือข่ายที่แตกต่างกันโดยอาศัยโปรโตคอลการสื่อสารที่แตกต่างกัน เป็นสื่อกลางของโบรกเกอร์ต่างๆรวมถึงโบรกเกอร์ DCOM, .NET remote และ Java CORBA

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

Broker implementation in CORBA

CORBA เป็นมาตรฐานสากลสำหรับ Object Request Broker ซึ่งเป็นตัวกลางในการจัดการการสื่อสารระหว่างอ็อบเจ็กต์แบบกระจายที่กำหนดโดย OMG (กลุ่มการจัดการอ็อบเจ็กต์)

สถาปัตยกรรมเชิงบริการ (SOA)

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

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

คุณสมบัติของ SOA

สถาปัตยกรรมที่มุ่งเน้นการบริการมีคุณสมบัติดังต่อไปนี้ -

  • Distributed Deployment - เปิดเผยข้อมูลขององค์กรและตรรกะทางธุรกิจเป็นหน่วยการทำงานที่เรียกว่าบริการอย่างหลวมคู่ค้นพบโครงสร้างตามมาตรฐานหยาบหยาบไร้สัญชาติ

  • Composability - รวบรวมกระบวนการใหม่จากบริการที่มีอยู่ซึ่งเปิดเผยในรายละเอียดที่ต้องการผ่านอินเทอร์เฟซการร้องเรียนที่กำหนดไว้อย่างดีเผยแพร่และมาตรฐาน

  • Interoperability - แบ่งปันความสามารถและนำบริการที่ใช้ร่วมกันมาใช้ซ้ำในเครือข่ายโดยไม่คำนึงถึงโปรโตคอลหรือเทคโนโลยีการใช้งาน

  • Reusability - เลือกผู้ให้บริการและเข้าถึงทรัพยากรที่มีอยู่ซึ่งเปิดเผยเป็นบริการ

การทำงานของ SOA

รูปต่อไปนี้แสดงให้เห็นว่า SOA ทำงานอย่างไร -

Advantages

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

  • ส่วนประกอบของบริการแต่ละส่วนไม่ขึ้นอยู่กับบริการอื่น ๆ เนื่องจากคุณลักษณะของบริการไร้สัญชาติ

  • การใช้บริการจะไม่ส่งผลกระทบต่อการใช้บริการตราบเท่าที่อินเทอร์เฟซที่เปิดเผยจะไม่เปลี่ยนแปลง

  • ลูกค้าหรือบริการใด ๆ สามารถเข้าถึงบริการอื่น ๆ ได้โดยไม่คำนึงถึงแพลตฟอร์มเทคโนโลยีผู้ขายหรือการใช้งานภาษา

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

  • การพัฒนาแอปพลิเคชันทางธุรกิจที่ใช้ SOA นั้นมีประสิทธิภาพมากกว่าในแง่ของเวลาและต้นทุน

  • ช่วยเพิ่มความสามารถในการปรับขนาดและให้การเชื่อมต่อมาตรฐานระหว่างระบบ

  • การใช้ 'บริการทางธุรกิจ' อย่างมีประสิทธิภาพและประสิทธิผล

  • การรวมจะง่ายขึ้นมากและปรับปรุงความสามารถในการทำงานร่วมกันภายใน

  • ความซับซ้อนเชิงนามธรรมสำหรับนักพัฒนาและทำให้กระบวนการทางธุรกิจใกล้ชิดกับผู้ใช้มากขึ้น

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

วัตถุประสงค์หลักของสถาปัตยกรรมตามส่วนประกอบคือเพื่อให้แน่ใจว่า component reusability. ส่วนประกอบจะห่อหุ้มฟังก์ชันการทำงานและลักษณะการทำงานขององค์ประกอบซอฟต์แวร์ไว้ในหน่วยไบนารีที่ใช้ซ้ำได้และสามารถปรับใช้งานได้เอง มีกรอบคอมโพเนนต์มาตรฐานมากมายเช่น COM / DCOM, JavaBean, EJB, CORBA, .NET, บริการเว็บและบริการกริด เทคโนโลยีเหล่านี้ใช้กันอย่างแพร่หลายในการออกแบบแอปพลิเคชัน GUI บนเดสก์ท็อปเฉพาะที่เช่นคอมโพเนนต์ JavaBean กราฟิกคอมโพเนนต์ MS ActiveX และคอมโพเนนต์ COM ซึ่งสามารถใช้ซ้ำได้โดยการลากและวาง

การออกแบบซอฟต์แวร์เชิงองค์ประกอบมีข้อดีหลายประการเหนือวิธีเชิงวัตถุแบบเดิมเช่น -

  • ลดเวลาในตลาดและต้นทุนการพัฒนาโดยการนำส่วนประกอบที่มีอยู่กลับมาใช้ใหม่

  • เพิ่มความน่าเชื่อถือด้วยการนำส่วนประกอบที่มีอยู่กลับมาใช้ใหม่

ส่วนประกอบคืออะไร?

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

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

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

มุมมองของส่วนประกอบ

ส่วนประกอบสามารถมีมุมมองที่แตกต่างกันได้สามมุมมอง - มุมมองเชิงวัตถุมุมมองทั่วไปและมุมมองที่เกี่ยวข้องกับกระบวนการ

Object-oriented view

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

Conventional view

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

Process-related view

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

  • คอมโพเนนต์ส่วนติดต่อผู้ใช้ (UI) ประกอบด้วยกริดปุ่มที่อ้างถึงการควบคุมและส่วนประกอบยูทิลิตี้จะแสดงฟังก์ชันย่อยเฉพาะที่ใช้ในส่วนประกอบอื่น ๆ

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

  • ส่วนประกอบจำนวนมากมองไม่เห็นซึ่งกระจายอยู่ในแอปพลิเคชันทางธุรกิจขององค์กรและเว็บแอปพลิเคชันทางอินเทอร์เน็ตเช่น Enterprise JavaBean (EJB) ส่วนประกอบ. NET และส่วนประกอบ CORBA

ลักษณะของส่วนประกอบ

  • Reusability- ส่วนประกอบมักได้รับการออกแบบมาเพื่อใช้ซ้ำในสถานการณ์ที่แตกต่างกันในการใช้งานที่แตกต่างกัน อย่างไรก็ตามส่วนประกอบบางอย่างอาจได้รับการออกแบบมาสำหรับงานเฉพาะ

  • Replaceable - ส่วนประกอบสามารถทดแทนได้อย่างอิสระด้วยส่วนประกอบอื่น ๆ ที่คล้ายคลึงกัน

  • Not context specific - ส่วนประกอบได้รับการออกแบบให้ทำงานในสภาพแวดล้อมและบริบทที่แตกต่างกัน

  • Extensible - ส่วนประกอบสามารถขยายจากส่วนประกอบที่มีอยู่เพื่อให้เกิดพฤติกรรมใหม่

  • Encapsulated - ส่วนประกอบ AA แสดงถึงอินเทอร์เฟซซึ่งอนุญาตให้ผู้โทรใช้ฟังก์ชันการทำงานและไม่เปิดเผยรายละเอียดของกระบวนการภายในหรือตัวแปรหรือสถานะภายในใด ๆ

  • Independent - ส่วนประกอบได้รับการออกแบบให้มีการพึ่งพาส่วนประกอบอื่น ๆ น้อยที่สุด

หลักการออกแบบตามส่วนประกอบ −

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

  • ระบบซอฟต์แวร์ถูกย่อยสลายเป็นหน่วยส่วนประกอบที่ใช้ซ้ำได้เหนียวและห่อหุ้ม

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

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

  • ขึ้นอยู่กับองค์ประกอบนามธรรมไม่ได้ขึ้นอยู่กับส่วนประกอบคอนกรีตอื่น ๆ ซึ่งเพิ่มความยากลำบากในการใช้จ่าย

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

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

  • สำหรับคลาสเซิร์ฟเวอร์ควรสร้างอินเทอร์เฟซเฉพาะเพื่อรองรับลูกค้าประเภทหลัก ๆ ควรระบุเฉพาะการดำเนินการที่เกี่ยวข้องกับไคลเอ็นต์ประเภทใดประเภทหนึ่งในอินเทอร์เฟซ

  • ส่วนประกอบสามารถขยายไปยังส่วนประกอบอื่น ๆ และยังคงมีจุดต่อขยายของตัวเอง เป็นแนวคิดของสถาปัตยกรรมที่ใช้ปลั๊กอิน สิ่งนี้ช่วยให้ปลั๊กอินสามารถเสนอปลั๊กอิน API อื่นได้

แนวทางการออกแบบระดับส่วนประกอบ

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

  • รับชื่อส่วนประกอบทางสถาปัตยกรรมจากโดเมนปัญหาและรับรองว่ามีความหมายต่อผู้มีส่วนได้ส่วนเสียทั้งหมดที่ดูแบบจำลองสถาปัตยกรรม

  • แยกเอนทิตีกระบวนการทางธุรกิจที่สามารถดำรงอยู่อย่างอิสระโดยไม่มีการพึ่งพาที่เกี่ยวข้องกับเอนทิตีอื่น

  • รับรู้และค้นพบเอนทิตีอิสระเหล่านี้เป็นส่วนประกอบใหม่

  • ใช้ชื่อองค์ประกอบโครงสร้างพื้นฐานที่แสดงถึงความหมายเฉพาะการนำไปใช้งาน

  • จำลองการอ้างอิงใด ๆ จากซ้ายไปขวาและการสืบทอดจากบนสุด (คลาสพื้นฐาน) ไปยังด้านล่าง (คลาสที่ได้รับ)

  • สร้างโมเดลการอ้างอิงคอมโพเนนต์ใด ๆ เป็นอินเทอร์เฟซแทนที่จะแสดงว่าเป็นการพึ่งพาคอมโพเนนต์โดยตรงกับคอมโพเนนต์

การดำเนินการออกแบบระดับส่วนประกอบ

รับรู้คลาสการออกแบบทั้งหมดที่สอดคล้องกับโดเมนปัญหาตามที่กำหนดไว้ในโมเดลการวิเคราะห์และโมเดลสถาปัตยกรรม

  • รับรู้คลาสการออกแบบทั้งหมดที่สอดคล้องกับโดเมนโครงสร้างพื้นฐาน

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

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

  • อธิบายขั้นตอนการประมวลผลภายในแต่ละการดำเนินการโดยละเอียดโดยใช้รหัสหลอกหรือแผนภาพกิจกรรม UML

  • อธิบายแหล่งข้อมูลถาวร (ฐานข้อมูลและไฟล์) และระบุคลาสที่จำเป็นในการจัดการ

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

  • ทำแผนภาพการปรับใช้อย่างละเอียดเพื่อให้รายละเอียดการใช้งานเพิ่มเติม

  • แสดงตำแหน่งของแพ็กเกจคีย์หรือคลาสของคอมโพเนนต์ในระบบโดยใช้คลาสอินสแตนซ์และกำหนดฮาร์ดแวร์และสภาพแวดล้อมระบบปฏิบัติการเฉพาะ

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

ข้อดี

  • Ease of deployment - เมื่อมีเวอร์ชันที่เข้ากันได้ใหม่ ๆ การเปลี่ยนเวอร์ชันที่มีอยู่แล้วจึงง่ายขึ้นโดยไม่มีผลกระทบต่อส่วนประกอบอื่น ๆ หรือระบบโดยรวม

  • Reduced cost - การใช้ส่วนประกอบของบุคคลที่สามช่วยให้คุณสามารถกระจายต้นทุนในการพัฒนาและบำรุงรักษา

  • Ease of development - ส่วนประกอบใช้อินเทอร์เฟซที่รู้จักกันดีเพื่อจัดเตรียมฟังก์ชันการทำงานที่กำหนดไว้ทำให้สามารถพัฒนาได้โดยไม่ส่งผลกระทบต่อส่วนอื่น ๆ ของระบบ

  • Reusable - การใช้ส่วนประกอบที่ใช้ซ้ำได้หมายความว่าสามารถใช้เพื่อกระจายต้นทุนการพัฒนาและการบำรุงรักษาไปยังแอพพลิเคชั่นหรือระบบต่างๆ

  • Modification of technical complexity - ส่วนประกอบปรับเปลี่ยนความซับซ้อนผ่านการใช้คอนเทนเนอร์ส่วนประกอบและบริการต่างๆ

  • Reliability - ความน่าเชื่อถือของระบบโดยรวมเพิ่มขึ้นเนื่องจากความน่าเชื่อถือของแต่ละองค์ประกอบช่วยเพิ่มความน่าเชื่อถือของทั้งระบบผ่านการใช้ซ้ำ

  • System maintenance and evolution - ง่ายต่อการเปลี่ยนแปลงและอัปเดตการใช้งานโดยไม่ส่งผลกระทบต่อส่วนที่เหลือของระบบ

  • Independent- ความเป็นอิสระและการเชื่อมต่อที่ยืดหยุ่นของส่วนประกอบ การพัฒนาส่วนประกอบอย่างอิสระตามกลุ่มต่างๆแบบขนาน ผลผลิตสำหรับการพัฒนาซอฟต์แวร์และการพัฒนาซอฟต์แวร์ในอนาคต

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

  • ยอมรับการป้อนข้อมูลของผู้ใช้

  • กำลังแสดงผลลัพธ์

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

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

  • อินเทอร์เฟซผู้ใช้ที่ดีต้องดึงดูดผู้ใช้ให้ใช้ระบบซอฟต์แวร์โดยไม่ผิดพลาด ควรช่วยให้ผู้ใช้เข้าใจระบบซอฟต์แวร์ได้ง่ายโดยไม่มีข้อมูลที่ทำให้เข้าใจผิด UI ที่ไม่ดีอาจทำให้ตลาดล้มเหลวจากการแข่งขันของระบบซอฟต์แวร์

  • UI มีไวยากรณ์และความหมาย ไวยากรณ์ประกอบด้วยประเภทส่วนประกอบเช่นข้อความไอคอนปุ่ม ฯลฯ และความสามารถในการใช้งานสรุปความหมายของ UI คุณภาพของ UI นั้นโดดเด่นด้วยรูปลักษณ์ (ไวยากรณ์) และการใช้งาน (ความหมาย)

  • โดยทั่วไปมีอินเทอร์เฟซผู้ใช้สองประเภทหลัก ๆ คือ a) Textual b) แบบกราฟิก

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

อินเทอร์เฟซผู้ใช้แบบกราฟิก

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

เป็นที่รู้จักกันในชื่อ WIMP interface เพราะใช้ประโยชน์จาก -

  • Windows - พื้นที่สี่เหลี่ยมบนหน้าจอที่แอปพลิเคชันที่ใช้กันทั่วไปทำงาน

  • Icons - รูปภาพหรือสัญลักษณ์ที่ใช้เพื่อแสดงถึงแอปพลิเคชันซอฟต์แวร์หรืออุปกรณ์ฮาร์ดแวร์

  • Menus - รายการตัวเลือกที่ผู้ใช้สามารถเลือกสิ่งที่ต้องการได้

  • Pointers- สัญลักษณ์เช่นลูกศรที่เคลื่อนที่ไปรอบ ๆ หน้าจอเมื่อผู้ใช้เลื่อนเมาส์ ช่วยให้ผู้ใช้เลือกวัตถุ

การออกแบบส่วนต่อประสานผู้ใช้

เริ่มต้นด้วยการวิเคราะห์งานซึ่งเข้าใจภารกิจหลักของผู้ใช้และโดเมนปัญหา ควรได้รับการออกแบบในแง่ของคำศัพท์ของผู้ใช้และเริ่มต้นจากงานของผู้ใช้มากกว่าโปรแกรมเมอร์

  • ในการวิเคราะห์อินเทอร์เฟซผู้ใช้ผู้ประกอบวิชาชีพจำเป็นต้องศึกษาและทำความเข้าใจองค์ประกอบ 4 ประการ -

    • users ใครจะโต้ตอบกับระบบผ่านอินเทอร์เฟซ

    • tasks ที่ผู้ใช้ปลายทางต้องดำเนินการเพื่อทำงานของตน

    • content ที่นำเสนอเป็นส่วนหนึ่งของอินเทอร์เฟซ

    • work environment ซึ่งงานเหล่านี้จะดำเนินการ

  • การออกแบบ UI ที่เหมาะสมหรือดีทำงานจากความสามารถและข้อ จำกัด ของผู้ใช้ไม่ใช่เครื่องจักร ในขณะที่ออกแบบ UI ความรู้เกี่ยวกับลักษณะของงานและสภาพแวดล้อมของผู้ใช้ก็มีความสำคัญเช่นกัน

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

    • The conceptual level - อธิบายเอนทิตีพื้นฐานโดยพิจารณาจากมุมมองของผู้ใช้ที่มีต่อระบบและการดำเนินการที่เป็นไปได้กับพวกเขา

    • The semantic level - อธิบายถึงฟังก์ชันที่ดำเนินการโดยระบบเช่นคำอธิบายข้อกำหนดการทำงานของระบบ แต่ไม่ได้ระบุถึงวิธีที่ผู้ใช้จะเรียกใช้ฟังก์ชัน

    • The syntactic level - อธิบายลำดับของอินพุตและเอาต์พุตที่จำเป็นในการเรียกใช้ฟังก์ชันที่อธิบายไว้

    • The lexical level - กำหนดว่าอินพุตและเอาต์พุตเกิดขึ้นจริงจากการทำงานของฮาร์ดแวร์แบบดั้งเดิมอย่างไร

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

    • กำหนดอ็อบเจ็กต์ส่วนติดต่อผู้ใช้และการดำเนินการ (การดำเนินการ)

    • กำหนดเหตุการณ์ (การกระทำของผู้ใช้) ที่จะทำให้สถานะของอินเทอร์เฟซผู้ใช้เปลี่ยนไป

    • ระบุวิธีที่ผู้ใช้ตีความสถานะของระบบจากข้อมูลที่ให้ผ่านอินเทอร์เฟซ

    • อธิบายสถานะของอินเทอร์เฟซแต่ละรายการตามที่ผู้ใช้ปลายทางเห็น

    กระบวนการพัฒนาส่วนต่อประสานผู้ใช้

    เป็นไปตามกระบวนการเกลียวดังแสดงในแผนภาพต่อไปนี้ -

    Interface analysis

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

    Interface design

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

    Interface construction

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

    Interface validation

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

    User Interface Models

    เมื่อมีการวิเคราะห์และออกแบบอินเทอร์เฟซผู้ใช้ต่อไปนี้สี่รุ่น -

    User profile model

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

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

    Design model

    • สร้างโดยวิศวกรซอฟต์แวร์ซึ่งรวมเอาข้อมูลสถาปัตยกรรมอินเทอร์เฟซและการแสดงขั้นตอนของซอฟต์แวร์

    • ได้มาจากรูปแบบการวิเคราะห์ข้อกำหนดและควบคุมโดยข้อมูลในข้อกำหนดข้อกำหนดซึ่งช่วยในการกำหนดผู้ใช้ระบบ

    Implementation model

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

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

    User's mental model

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

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

    ข้อควรพิจารณาในการออกแบบส่วนต่อประสานผู้ใช้

    ผู้ใช้เป็นศูนย์กลาง

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

    เรียบง่ายและใช้งานง่าย

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

    วางผู้ใช้ในการควบคุม

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

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

    ความโปร่งใส

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

    ใช้การเปิดเผยแบบก้าวหน้า

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

    ความสม่ำเสมอ

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

    บูรณาการ

    ระบบซอฟต์แวร์ควรรวมเข้ากับแอปพลิเคชันอื่น ๆ เช่น MS notepad และ MS-Office ได้อย่างราบรื่น สามารถใช้คำสั่งคลิปบอร์ดโดยตรงเพื่อทำการแลกเปลี่ยนข้อมูล

    เชิงส่วนประกอบ

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

    ปรับแต่งได้

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

    ลดภาระหน่วยความจำของผู้ใช้

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

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

    การแยก

    UI ต้องแยกออกจากตรรกะของระบบผ่านการใช้งานเพื่อเพิ่มความสามารถในการใช้ซ้ำและการบำรุงรักษา

    วิธีการทำซ้ำและเพิ่มหน่วย

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

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

    ระบุเป้าหมายสถาปัตยกรรม

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

    ขั้นตอนนี้ประกอบด้วยกิจกรรมต่อไปนี้ -

    • ระบุเป้าหมายสถาปัตยกรรมของคุณตั้งแต่เริ่มต้น
    • ระบุผู้บริโภคสถาปัตยกรรมของเรา
    • ระบุข้อ จำกัด

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

    สถานการณ์สำคัญ

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

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

    ภาพรวมแอปพลิเคชัน

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

    ระบุประเภทแอปพลิเคชัน

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

    ระบุข้อ จำกัด ในการปรับใช้

    เลือกโทโพโลยีการปรับใช้ที่เหมาะสมและแก้ไขข้อขัดแย้งระหว่างแอปพลิเคชันและโครงสร้างพื้นฐานเป้าหมาย

    ระบุรูปแบบการออกแบบสถาปัตยกรรมที่สำคัญ

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

    ระบุเทคโนโลยีที่เกี่ยวข้อง

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

    ประเด็นสำคัญหรือจุดสำคัญ

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

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

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

    โซลูชั่นสำหรับผู้สมัคร

    หลังจากกำหนดคีย์ฮอตสปอตแล้วให้สร้างสถาปัตยกรรมพื้นฐานเริ่มต้นหรือการออกแบบระดับสูงอันดับแรกจากนั้นเริ่มกรอกรายละเอียดเพื่อสร้างสถาปัตยกรรมผู้สมัคร

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

    ตรวจสอบการออกแบบโซลูชันของผู้สมัครกับสถานการณ์สำคัญและข้อกำหนดที่กำหนดไว้แล้วก่อนที่จะทำตามวงจรซ้ำและปรับปรุงการออกแบบ

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

    รีวิวสถาปัตยกรรม

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

    • ทบทวนสถาปัตยกรรมบ่อยครั้งตามเหตุการณ์สำคัญของโครงการและเพื่อตอบสนองต่อการเปลี่ยนแปลงทางสถาปัตยกรรมที่สำคัญอื่น ๆ

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

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

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

    วิธีการวิเคราะห์สถาปัตยกรรมซอฟต์แวร์ (SAAM)

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

    วิธีการวิเคราะห์การแลกเปลี่ยนทางสถาปัตยกรรม (ATAM)

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

    การทบทวนการออกแบบที่ใช้งานอยู่ (ADR)

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

    บทวิจารณ์ที่ใช้งานอยู่ของการออกแบบระดับกลาง (ARID)

    มันรวมแง่มุม ADR ของการตรวจสอบสถาปัตยกรรมที่กำลังดำเนินการโดยมุ่งเน้นไปที่ชุดของปัญหาและแนวทาง ATAM และ SAAM ของการทบทวนตามสถานการณ์โดยเน้นที่คุณลักษณะด้านคุณภาพ

    วิธีการวิเคราะห์ต้นทุนผลประโยชน์ (CBAM)

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

    Architecture Level Modifiability Analysis (ALMA)

    ประมาณการความสามารถในการปรับเปลี่ยนสถาปัตยกรรมสำหรับระบบสารสนเทศทางธุรกิจ (BIS)

    วิธีการประเมินสถาปัตยกรรมครอบครัว (FAAM)

    โดยประมาณสถาปัตยกรรมตระกูลระบบสารสนเทศสำหรับการทำงานร่วมกันและความสามารถในการขยาย

    การสื่อสารการออกแบบสถาปัตยกรรม

    หลังจากเสร็จสิ้นการออกแบบสถาปัตยกรรมเราต้องสื่อสารการออกแบบกับผู้มีส่วนได้ส่วนเสียอื่น ๆ ซึ่งรวมถึงทีมพัฒนาผู้ดูแลระบบผู้ปฏิบัติงานเจ้าของธุรกิจและผู้ที่สนใจอื่น ๆ

    มีหลายวิธีที่รู้จักกันดีในการอธิบายสถาปัตยกรรมให้กับผู้อื่นดังต่อไปนี้: -

    4 + 1 รุ่น

    แนวทางนี้ใช้ห้ามุมมองของสถาปัตยกรรมที่สมบูรณ์ สี่มุมมอง (ไฟล์logical view, ที่ process view, ที่ physical view, และ development view) อธิบายสถาปัตยกรรมจากแนวทางต่างๆ มุมมองที่ห้าแสดงสถานการณ์และกรณีการใช้งานสำหรับซอฟต์แวร์ ช่วยให้ผู้มีส่วนได้ส่วนเสียเห็นคุณสมบัติของสถาปัตยกรรมที่พวกเขาสนใจเป็นพิเศษ

    ภาษาคำอธิบายสถาปัตยกรรม (ADL)

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

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

    การสร้างแบบจำลองที่คล่องตัว

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

    เอกสารรุ่น Agile กำหนดเป้าหมายลูกค้าเฉพาะและตอบสนองความพยายามในการทำงานของลูกค้ารายนั้น ความเรียบง่ายของเอกสารช่วยให้มั่นใจได้ว่ามีการมีส่วนร่วมของผู้มีส่วนได้ส่วนเสียในการสร้างแบบจำลองของสิ่งประดิษฐ์

    IEEE 1471

    IEEE 1471 เป็นชื่อย่อของมาตรฐานที่รู้จักกันอย่างเป็นทางการในชื่อ ANSI / IEEE 1471-2000“ แนวทางปฏิบัติที่แนะนำสำหรับคำอธิบายสถาปัตยกรรมของ Software-Intensive Systems” IEEE 1471 ปรับปรุงเนื้อหาของคำอธิบายสถาปัตยกรรมโดยเฉพาะโดยให้ความหมายที่เฉพาะเจาะจงกับบริบทมุมมองและมุมมอง

    ภาษาการสร้างแบบจำลองแบบรวม (UML)

    แนวทางนี้แสดงถึงสามมุมมองของแบบจำลองระบบ functional requirements view (ข้อกำหนดการทำงานของระบบจากมุมมองของผู้ใช้รวมถึงกรณีการใช้งาน); the static structural view(วัตถุคุณลักษณะความสัมพันธ์และการดำเนินการรวมทั้งคลาสไดอะแกรม); และdynamic behavior view (การทำงานร่วมกันระหว่างอ็อบเจ็กต์และการเปลี่ยนแปลงสถานะภายในของอ็อบเจ็กต์รวมถึงลำดับกิจกรรมและไดอะแกรมสถานะ)

ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved