9.0. Software Design.md

"" Software Design and Implementation Week 09

หัวข้อที่จะศึกษา

• Object-oriented design using the UML
• Design patterns
• Implementation issues
• Open source development Design and implementation
• การออกแบบและสร้างซอฟต์แวร์เป็นขั้นตอนหนึ่งในกระบวนการวิศวกรรมซอฟต์แวร์
• เป็นกระบวนการที่ทำให้เกิดซอฟต์แวร์ที่ใช้งานได้จริง (executable software) ขึ้นมา
• การออกแบบและการสร้างซอฟต์แวร์เป็นกระบวนการที่ต้องดำเนินการควบคู่กันเสมอ
• การออกแบบซอฟต์แวร์ (software design) เป็นกิจกรรมที่สร้างสรรค์ หมายความว่าต้องสร้างสิ่งที่ยังไม่มีอยู่
• เราต้องสร้างส่วนประกอบซอฟต์แวร์และจัดการความสัมพันธ์ของส่วนประกอบเหล่านั้น ตามความต้องการของลูกค้า
• การดำเนินการสร้างซอฟต์แวร์ (software implementation) เป็นกระบวนการทำให้ แบบกลายเป็นโปรแกรม
• ต้องใช้ความสามารถด้านการ programming Build or buy
• โดส่วนใหญ่แล้ว ในหลาย ๆ โดเมนเราสามารถซื้อระบบที่พัฒนาเสร็จแล้วที่สามารถปรับแต่งตามความต้องการของผู้ใช้
• ตัวอย่างเช่น ถ้าลูกค้าต้องการใช้ระบบเวชระเบียนในโรงพยาบาล เราสามารถซื้อแพคเกจที่ใช้ในโรงพยาบาลอื่น ๆ มาดัดแปลง
• อาจจะถูกกว่าและเร็วกว่าที่จะพัฒนาระบบขึ้นมาใหม่ทั้งหมด
• ถ้าเราเลือกวิธีการพัฒนาในลักษณะนี้ งาน implementation จะเทไปทางด้าน configuration management แทนที่จะเป็น programming
• การเก็บ requirement ก็อาจจะต่างออกไป Object-oriented design using the UML An object-oriented design process
• กระบวนการออกแบบเชิงวัตถุ มีโมเดลต่าง ๆ ให้ใช้งานจำนวนมาก
• ในการพัฒนาและบำรุงรักษาโมเดลเหล่านั้นจะต้องใช้ความพยายามและทรัพยากรเป็นจำนวนมาก
• อาจไม่คุ้มค่าสำหรับระบบขนาดเล็ก ๆ
• สำหรับระบบขนาดใหญ่ที่พัฒนาขึ้นโดยกลุ่มคนจำนวนมาก การออกแบบโมเดลถือเป็นกลไกการสื่อสารที่สำคัญ ที่จะนำไปสู่ความสำเร็จ Process stages
• ในการออกแบบระบบ มีกระบวนการที่แตกต่างกันหลายรูปแบบ ขึ้นอยู่กับวัตถุประสงค์ของงาน
• โดยทั่วไป กิจกรรมในกระบวนการจะประกอบด้วย
• การกำหนดบริบทและรูปแบบการใช้งานระบบ
• การออกแบบสถาปัตยกรรมระบบ
• การระบุวัตถุหลักในระบบ
• การออกแบบและพัฒนาแบบจำลอง
• การกดำหนดการเชื่อมโยงความสัมพันธ์ระหว่างวัตถุในระบบ

System context and interactions

• ทำความเข้าใจความสัมพันธ์ระหว่างซอฟต์แวร์ที่ออกแบบและสภาพแวดล้อมภายนอก
• เป็นสิ่งสำคัญสำหรับการตัดสินใจว่าจะสร้างระบบที่มีการทำงานอย่างไร
• สามารถกำหนดวิธีจัดโครงสร้างระบบเพื่อสื่อสารกับสภาพแวดล้อม
• ทำความเข้าใจบริบทของระบบ
• ช่วยให้สามารถกำหนดขอบเขตของระบบ
• ช่วยให้ตัดสินใจได้ว่า จะบรรจุคุณลักษณะใดในระบบที่ออกแบบและใช้งานคุณลักษณะใดจากระบบอื่นที่เกี่ยวข้อง Context and interaction models
• แบบจำลองบริบทของระบบ (context model)
• เป็นแบบจำลองโครงสร้างที่แสดงให้เห็นถึงระบบอื่น ๆ ที่อยู่ในสภาพแวดล้อมของระบบที่พัฒนา
• แบบจำลองการโต้ตอบ (interaction model)
• เป็นแบบจำลองไดนามิก ที่แสดงให้เห็นว่าระบบมีปฏิสัมพันธ์กับสภาพแวดล้อมในขณะต่าง ๆ อย่างไร System context for the weather station Weather station use cases Use case description—Report weather Architectural design
• เมื่อเข้าใจปฏิสัมพันธ์ระหว่างระบบกับสิ่งแวดล้อมแล้ว เราสามารถใช้ข้อมูลนี้ในการออกแบบสถาปัตยกรรมระบบ
• เริ่มจากการระบุส่วนประกอบสำคัญ ๆ ที่ประกอบกันเป็นส่วนหนึ่งของระบบและปฏิสัมพันธ์ของพวกมัน
• จากนั้นอาจจัดองค์ประกอบต่าง ๆ โดยใช้รูปแบบสถาปัตยกรรมที่เป็นมาตรฐาน เช่น แบบเลเยอร์ (layer) หรือ แบบไคลเอ็นต์เซิร์ฟเวอร์ (client-server)
• สถานีอากาศประกอบด้วยระบบย่อยอิสระ ที่สื่อสารโดยการส่งข้อความ (message broadcasting) High-level architecture of the weather station Architecture of data collection system Object class identification
• การระบุ object class มักเป็นส่วนที่ยากในการออกแบบเชิงวัตถุ
• ไม่มี 'สูตรสำเร็จ' สำหรับการออกแบบวัตถุ มันขึ้นอยู่กับทักษะประสบการณ์และความรู้เกี่ยวกับโดเมนของนักออกแบบระบบ
• การระบุวัตถุเป็นกระบวนการซ้ำซ้อน ที่ต้องทำซ้ำจนกว่าจะเป็นที่น่าพอใจ
• ไม่มีใครที่จะทำได้สำเร็จอย่างงดงามได้ในครั้งแรก หรือเพียงรอบเดียว Approaches to identification
• อธิบายระบบ โดยใช้วิธีการทางไวยากรณ์ตามภาษาธรรมชาติ
• อธิบายวัตถุ โดยใช้สิ่งที่จับต้องได้ในโดเมนเป็นจุดอ้างอิง
• อธิบายพฤติกรรม ระบุวัตถุตามการมีส่วนร่วมในพฤติกรรมนั้น
• วิเคราะห์สถานการณ์ แล้วระบุ object, attribute และ method ตามแต่ละสถานการณ์ Weather station object classes
• การระบุ object class ในระบบสถานีวัดอากาศอาจพิจารณาจากฮาร์ดแวร์ที่จับต้องได้รวมทั้งข้อมูลในระบบ เช่น
• เครื่องวัดอุณหภูมิภาคพื้นดิน, เครื่องวัดความเร็วลม, บารอมิเตอร์
• เป็นวัตถุของโดเมนแอ็พพลิเคชันซึ่งเป็น "ฮาร์ดแวร์" ที่เกี่ยวข้องกับเครื่องมือในระบบ
• สถานีอากาศ
• ประกอบด้วยส่วนติดต่อพื้นฐานของสถานีอากาศกับสภาพแวดล้อม ดังการโต้ตอบที่ระบุไว้ในแบบจำลอง use case
• ข้อมูลสภาพอากาศ
• ประกอบด้วยข้อมูลจากเครื่องมือวัดต่าง ๆ Weather station object classes Design models
• design model แสดง object และ object class รวมทั้งความสัมพันธ์ระหว่างสิ่งเหล่านั้น
• design model มีสองรูปแบบ ได้แก่
• โมเดลแบบโครงสร้าง อธิบายถึงโครงสร้างแบบคงที่ของระบบในแง่ของคลาสวัตถุและความสัมพันธ์
• โมเดลแบบไดนามิก อธิบายปฏิสัมพันธ์แบบไดนามิกระหว่างวัตถุ Examples of design models
• แบบจำลองระบบย่อยที่แสดงการจัดกลุ่มของ object ในระบบ (subsystem model)
• แบบจำลองแสดงลำดับของการโต้ตอบของวัตถุ (sequence model)
• แบบจำลองที่แสดงให้เห็นว่า object เปลี่ยนสถานะอย่างไรเพื่อตอบสนองต่อเหตุการณ์ (State machine models)
• แบบจำลองอื่น ๆ เช่น use-case models, aggregation models, generalisation models, เป็นต้น Subsystem models
• แสดงการจัดวางระบบโดยให้ object ที่เกี่ยวข้องกันอยู่รวมกันอย่างเป็นหมวดหมู่
• ใน UML วัตถุเหล่านี้จะแสดงรวมกันเป็นแพคเกจ (package) โดยมีแนวคิด encapsulation เป็นสำคญ
• แบบจำลองนี้จะเป็นเชิงตรรกะ
• ในการจัดองค์ประกอบที่แท้จริงของวัตถุในแต่ละระบบอาจแตกต่างกัน Sequence models
• แสดงลำดับการโต้ตอบของอ็อบเจ็กต์ที่เกิดขึ้นตามเวลา
• วัตถุเรียงตามแนวนอนอยู่ด้านบน
• เวลาจะแสดงในแนวตั้ง แสดงลำดับเหตุการณ์จากบนลงล่าง
• ปฏิสัมพันธ์แสดงด้วยลูกศรที่มีป้ายกำกับ
• ลูกศรที่มีรูปแบบแตกต่างกัน แสดงถึงปฏิสัมพันธ์ที่แตกต่างกัน
• รูปสี่เหลี่ยมผืนผ้าบาง ๆ ในเส้นชีวิตของวัตถุ แสดงถึงระยะเวลาที่วัตถุเป็นตัวควบคุมในระบบ Sequence diagram describing data collection State diagrams
• แผนผังสถานะ (state diagram) ใช้เพื่อ
• แสดงวิธีที่วัตถุตอบสนองต่อคำขอบริการต่าง ๆ
• การเปลี่ยนสถานะที่เรียกใช้โดยคำขอเหล่านั้น
• แผนผังสถานะเป็นโมเดลระดับสูง
• แสดงพฤติกรรมในขณะทำงานของวัตถุ
• ไม่จำเป็นต้องมีแผนภาพ state diagram สำหรับ object ทั้งหมดในระบบ
• Object จำนวนมากในระบบมีความเรียบง่าย
• แบบจำลอง state diagram จะเพิ่มรายละเอียดที่ไม่จำเป็นให้กับการออกแบบ Weather station state diagram Design patterns Design patterns
• Design pattern เป็นวิธีการ reuse ความรู้เชิงนามธรรมเกี่ยวกับปัญหาและแนวทางแก้ไข
• Pattern คือคำอธิบายของปัญหาและสาระสำคัญของการแก้ปัญหา
• Pattern เป็นนามธรรมเพียงพอที่จะนำมาใช้ซ้ำ โดยปรับแต่งเล็ก ๆ น้อย ๆ
• Pattern descriptions มักใช้ประโยชน์จากลักษณะเชิงวัตถุ เช่น inheritance และ polymorphism Pattern elements
• Name
• Identifier ของ pattern ที่สื่อความหมายชัดเจน
• Problem description.
• Solution description.
• ไม่ใช่การออกแบบที่เป็นรูปธรรม
• เป็นเพียงเทมเพลตสำหรับการออกแบบที่สามารถปรับใช้งานได้ในรูปแบบต่าง ๆ
• Consequences
• ผลกระทบและเงื่อนไขในการตัดสินใจใช้ pattern นั้น ๆ The Observer pattern
• Name
• Observer.
• Description
• แยกการแสดงสถานะของ object ออกจาก ตัว object
• Problem description
• ใช้เมื่อจำเป็นต้องแสดงสถานะของ state ได้หลายสถานะ
• Solution description
• ดูสไลด์หน้าถัดไป
• Consequences
• การ Optimisations เพื่อเพิ่ม performance ในการแดงผลอาจทำได้ยาก The Observer pattern (1) The Observer pattern (2) Multiple displays using the Observer pattern A UML model of the Observer pattern Design problems
• หากต้องการใช้ design pattern ต้องแน่ใจว่าปัญหาด้านการออกแบบที่เรากำลังเจอ
• มี pattern ที่เกี่ยวข้องซึ่งสามารถนำมาใช้ได้ เช่น
• บอก object ต่าง ๆ ว่า object หนึ่งมีการเปลี่ยนแปลงสถานะ (Observer pattern)
• จัดระเบียบส่วนติดต่อกับ object ที่ได้รับการพัฒนาแบบ incremental (Façade pattern)
• จัดเตรียมวิธีการมาตรฐานในการเข้าถึง element ในคอลเล็กชัน โดยไม่คำนึงถึงว่าคอลเล็กชันดังกล่าวมีการสร้างอย่างไร (Iterator pattern)
• อนุญาตให้มีการขยายฟังก์ชันการทำงานของคลาสที่มีอยู่ในขณะทำงาน (run-time) (Decorator pattern) Implementation issues Implementation issues
• การ implement ในที่นี้ ไม่ได้หมายถึงการเขียนโปรแกรม (แม้ว่าการเขียนโปรแกรมจะเป็นสิ่งสำคัญอย่างชัดเจน) แต่ยังมีประเด็นการใช้งานอื่น ๆ ที่มักไม่ครอบคลุมในตำราการเขียนโปรแกรม เช่น
• Reuse ซอฟต์แวร์ที่ทันสมัยที่สุดในปัจจุบัน ถูกสร้างขึ้นโดยนำส่วนประกอบหรือระบบที่มีอยู่เดิมมาใช้ใหม่
• เมื่อต้องการพัฒนาซอฟต์แวร์ ควรใช้ code ที่มีอยู่ให้มากที่สุดเท่าที่จะเป็นไปได้
• Configuration management ในระหว่างขั้นตอนการพัฒนา จะมีหลาย ๆ เวอร์ชันของส่วนประกอบซอฟต์แวร์แต่ละตัวในระบบที่ต้องคอยจัดการการกำหนดค่า
• Host-target development – เป้าหมายในการผลิตซอฟต์แวร์มักไม่ใช้คอมพิวเตอร์เครื่องเดียวกับสภาพแวดล้อมในการพัฒนาซอฟต์แวร์ โดยส่วนใหญ่มักจะมีการพัฒนาบนคอมพิวเตอร์เครื่องหนึ่ง (ระบบโฮสต์) และรันบนคอมพิวเตอร์เครื่องหนึ่ง (ระบบเป้าหมาย) Reuse
• จากทศวรรษที่ 1960 ถึง 1990 ซอฟท์แวร์ใหม่ ๆ ได้รับการพัฒนาตั้งแต่เริ่มต้น (กระดาษเปล่า) โดยการเขียนโค้ดทั้งหมดในภาษาโปรแกรมระดับสูง
• มีการ reuse ที่สำคัญเพียงอย่างเดียวคือการใช้ฟังก์ชันและไลบรารี
• วิธีนี้ดูเหมือนจะไม่สามารถใช้งานได้มากขึ้นเรื่อย ๆ
• โดยเฉพาะอย่างยิ่งสำหรับระบบเชิงพาณิชย์และอินเทอร์เน็ต
• แรงกดดันที่สำคัญคือ ค่าใช้จ่ายและเวลาที่จะวางตลาด
• การพัฒนาซอฟต์แวร์โดยอาศัยการ reuse นั้นมีอยู่และเกิดขึ้นมานานแล้วสำหรับซอฟต์แวร์ทางธุรกิจและวิทยาศาสตร์ Reuse levels
• The abstraction level
• ในระดับนี้เราไม่ได้ reuse ซอฟต์แวร์โดยตรง แต่ใช้ความรู้เกี่ยวกับการออกแบบซอฟต์แวร์ที่ประสบความสำเร็จ
• The object level
• ในระดับนี้ เรานำวัตถุมาใช้ใหม่จากไลบรารีโดยตรงแทนที่จะเขียนโค้ดด้วยตัวเอง
• The component level
• component คือชุดของ objects และ classes ที่นำมาใช้ใหม่ใน application systems
• The system level
• ในระดับนี้เราจะ reuse ระบบแอ็พพลิเคชันทั้งหมด

Software reuse Reuse costs

• ต้นทุนจากเวลาที่ใช้ในการมองหาซอฟต์แวร์เพื่อ reuse และประเมินว่าเป็นไปตามความต้องการหรือไม่
• ค่าใช้จ่ายในการซื้อซอฟต์แวร์ที่สามารถ reuse ได้
• สำหรับระบบ COTS (commercial of the shelf) ขนาดใหญ่ อาจมีค่าใช้จ่ายนี้ที่สูงมาก
• ค่าใช้จ่ายในการปรับ (adapt) และกำหนดค่า (configuring) ส่วนประกอบหรือระบบซอฟต์แวร์ที่นำมา reuse ให้ตรงกับความต้องการของระบบที่กำลังพัฒนา
• ค่าใช้จ่ายในการรวม (integrating) ส่วนประกอบซอฟต์แวร์ที่นำมา reuse
• ถ้าใช้ซอฟต์แวร์จากแหล่งต่าง ๆ ร่วมกับรหัสใหม่ที่เราพัฒนาขึ้น Configuration management
• Configuration management คือชื่อที่กำหนดให้กับกระบวนการทั่วไปในการจัดการการเปลี่ยนแปลงซอฟต์แวร์
• จุดมุ่งหมายของ Configuration management คือการสนับสนุนกระบวนการรวมระบบ
• เพื่อให้นักพัฒนาซอฟต์แวร์ทุกคนสามารถเข้าถึงรหัสโครงการและเอกสาร
• เพื่อให้นักพัฒนาซอฟต์แวร์ตรวจสอบว่ามีการเปลี่ยนแปลงอะไรบ้าง
• เพื่อให้นักพัฒนาซอฟต์แวร์คอมไพล์และเชื่อมโยงองค์ประกอบเพื่อสร้างระบบ Configuration management activities
• Version management
• สามารถติดตามส่วนประกอบของซอฟต์แวร์เวอร์ชันต่างๆ
• ระบบการจัดการเวอร์ชัน ประกอบด้วยสิ่งอำนวยความสะดวกในการร่วมพัฒนาโดยโปรแกรมเมอร์หลาย ๆ คน
• System integration
• ช่วยให้นักพัฒนาสามารถกำหนดรุ่นของส่วนประกอบที่จะใช้ในการสร้างแต่ละรุ่นของระบบ
• ใช้เพื่อสร้างระบบโดยอัตโนมัติ โดยการรวบรวมและเชื่อมโยงส่วนประกอบที่จำเป็น
• Problem tracking
• เพื่อให้ผู้ใช้รายงานข้อผิดพลาดและปัญหาอื่น ๆ
• เพื่อให้นักพัฒนาซอฟต์แวร์ทั้งหมดสามารถดูว่าใครกำลังทำงานเกี่ยวกับปัญหาเหล่านี้และแก้ไขปัญหาเมื่อใด Configuration management tool interaction Host-target development
• ซอฟต์แวร์ส่วนใหญ่ (แทบทั้งหมด) ได้รับการพัฒนาบนคอมพิวเตอร์หนึ่งเครื่อง (host) แต่ทำงานบนเครื่องอื่น ๆ (target)
• โดยทั่วไปเรามักจะเรียกว่า development platform และ execution platform
• platform ไม่ได้หมายถึงแค่ ฮาร์ดแวร์
• platform ประกอบด้วยระบบปฏิบัติการที่ติดตั้งไว้พร้อมทั้งซอฟต์แวร์สนับสนุนอื่น ๆ เช่น database management system, development platforms, interactive development environment เป็นต้น
• development platform มักจะมีซอฟท์แวร์ติดตั้งมากกว่า execution platform
• platform เหล่านี้อาจมีสถาปัตยกรรมที่แตกต่างกัน Host-target development Development platform tools
• ระบบ Integrated compiler และการแก้ไขตามไวยากรณ์ (syntax-directed editing )
• ช่วยให้สามารถสร้าง แก้ไข และคอมไพล์โค้ดได้
• ระบบดีบักภาษา
• เครื่องมือแก้ไขกราฟิก เช่น เครื่องมือเพื่อแก้ไข UML
• เครื่องมือทดสอบเช่น Junit ที่สามารถรันชุดทดสอบในโปรแกรม version ใหม่ได้โดยอัตโนมัติ
• เครื่องมือสนับสนุนโครงการที่ช่วยจัดระเบียบ code สำหรับ project ต่างๆ Integrated development environments (IDEs)
• เครื่องมือการพัฒนาซอฟต์แวร์มักถูกจัดกลุ่มเพื่อสร้างสภาพแวดล้อมการพัฒนาแบบรวม (IDE)
• IDE คือชุดเครื่องมือซอฟต์แวร์ที่สนับสนุนด้านต่าง ๆ ของการพัฒนาซอฟต์แวร์
• มักจะประกอบด้วย common framework และ user interface
• IDEs ถูกสร้างขึ้นเพื่อสนับสนุนการพัฒนาในภาษาการเขียนโปรแกรมเฉพาะ
• เช่น Java IDE อาจได้รับการพัฒนาขึ้นเป็นพิเศษ
• หรืออาจเป็น IDE ทั่ว ๆ ไป แล้วมีเครื่องมือสนับสนุนภาษาเฉพาะให้เลือกใช้ (เช่น eclipse, vscode) Open source development Open source development
• การพัฒนา open source เป็นแนวทางในการพัฒนาซอฟต์แวร์ซึ่งมีการเผยแพร่ซอร์สโค้ดของระบบซอฟต์แวร์และเปิดโอกาสให้อาสาสมัครได้เข้าร่วมในกระบวนการพัฒนา
• จุดเริ่มต้นเกิดจาก Free Software Foundation (www.fsf.org) ซึ่งสนับสนุนว่าซอร์สโค้ดไม่ควรเป็นกรรมสิทธิ์ แต่ควรมีให้ผู้ใช้สามารถตรวจสอบและแก้ไขได้ตามต้องการ
• ซอฟต์แวร์ open source ขยายแนวคิดนี้โดยใช้อินเทอร์เน็ตเพื่อรับสมัครนักพัฒนาอาสาสมัครจำนวนมากขึ้น Open source systems
• ผลิตภัณฑ์ open source ที่รู้จักกันดีคือระบบปฏิบัติการ Linux ซึ่งใช้กันอย่างแพร่หลายในฐานะระบบเซิร์ฟเวอร์และเป็นสภาพแวดล้อมเดสก์ท็อป
• ผลิตภัณฑ์ open source ที่สำคัญอื่น ๆ ได้แก่ Java, เว็บเซิร์ฟเวอร์ Apache และระบบจัดการฐานข้อมูล mySQL Open source issues
• ผลิตภัณฑ์ที่มีการพัฒนาควรใช้ส่วนประกอบ open source หรือไม่?
• ควรใช้วิธี open source เพื่อการพัฒนาซอฟต์แวร์หรือไม่? Open source business
• มีบริษัทจำนวนมากขึ้นเรื่อย ๆ ที่กำลังใช้แนวทาง open source ในการพัฒนา
• รูปแบบธุรกิจของพวกเขาไม่ได้ขึ้นอยู่กับการขายผลิตภัณฑ์ซอฟต์แวร์
• แต่ขายการ support ผลิตภัณฑ์นั้น
• พวกเขาเชื่อว่าการมีส่วนร่วมของชุมชน open source จะช่วยให้ซอฟต์แวร์สามารถพัฒนาได้อย่างรวดเร็ว
• จะสร้างชุมชนของผู้ใช้ซอฟต์แวร์ได้เร็วยิ่งขึ้น
• จะขายการ support ได้มากขึ้น Open source licensing
• หลักการพื้นฐานของการพัฒนา open source คือซอร์สโค้ดควรมีอิสระในการใช้งาน
• แต่ไม่ได้หมายความว่าทุกคนสามารถทุกย่างที่ต้องการกับซอร์สโค้ดนั้น
• ตามกฎหมาย ผู้พัฒนา code (ทั้งบริษัทหรือบุคคล) ยังคงเป็นเจ้าของโค้ดอยู่
• พวกเขาสามารถวางข้อจำกัดเกี่ยวกับวิธีการใช้ โดยการรวมเงื่อนไขที่มีผลผูกพันตามกฎหมายในใบอนุญาตซอฟต์แวร์ open source
• นักพัฒนาซอฟต์แวร์ open source บางคนเชื่อว่าหากใช้ส่วนประกอบ open source ในการพัฒนาระบบใหม่ ระบบดังกล่าวควรเป็น open source ด้วย
• นักพัฒนาซอฟต์แวร์บางคนยินดีที่จะอนุญาตให้ใช้ code ของตนโดยไม่มีข้อจำกัด
• ซึ่งบางครั้งระบบที่พัฒนาแล้วอาจเป็นกรรมสิทธิ์และจำหน่ายในรูปแบบระบบปิด License models
• GNU General Public License (GPL)
• หรือใบอนุญาตที่เรียกว่า 'reciprocal' ซึ่งหมายความว่าหากเราใช้ซอฟต์แวร์ open source ที่ได้รับอนุญาตภายใต้ใบอนุญาต GPL เราต้องทำซอฟต์แวร์นั้นให้เป็น open source ด้วย
• GNU Lesser General Public License (LGPL)
• เป็นรูปแบบใบอนุญาต GPL ที่เราสามารถเขียน code ที่เชื่อมโยงไปยัง open source โดยไม่ต้องเผยแพร่แหล่งที่มาของ component เหล่านั้น
• ใบอนุญาตจัดจำหน่ายมาตรฐาน Berkley (BSD)
• เป็นใบอนุญาตแบบ non-reciprocal ซึ่งหมายความว่า ไม่จำเป็นต้องเผยแพร่การเปลี่ยนแปลงหรือแก้ไขใด ๆ ที่ทำกับ open source
• สามารถใช้ code ในระบบที่เป็นกรรมสิทธิ์ที่ขายได้ License management
• สร้างระบบ เพื่อดูแลรักษาข้อมูลเกี่ยวกับส่วนประกอบ open source ที่ดาวน์โหลดและใช้
• ศึกษาถึงใบอนุญาตประเภทต่าง ๆ และทำความเข้าใจว่า component ที่ได้รับอนุญาตมีการใช้งานอย่างไร
• ระวังเส้นทางการพัฒนาของส่วนประกอบต่างๆ
• ให้ความรู้บุคคลต่าง ๆ เกี่ยวกับ open source
• ให้มีการตรวจสอบระบบได้ ว่ามี open source อยู่หรือไม่
• มีส่วนร่วมในชุมชน open source

Key points

• การออกแบบและการใช้งานซอฟต์แวร์เป็นกิจกรรมที่เกี่ยวเนื่องกัน
• ระดับของรายละเอียดในการออกแบบขึ้นอยู่กับประเภทของระบบ ไม่ว่าจะใช้วิธีการใด เช่น plan-driven หรือ agile
• กระบวนการของการออกแบบเชิงวัตถุ ประกอบด้วยกิจกรรมในการออกแบบสถาปัตยกรรมระบบ, การระบุออบเจ็กต์ในระบบ, การอธิบายการออกแบบโดยใช้โมเดลวัตถุที่แตกต่างกัน และการจัดทำเอกสารอธิบายการรวมระบบ
• กระบวนการออกแบบเชิงวัตถุ ทำให้เกิดแบบจำลองที่หลากหลาย เช่น
• โมเดลแบบ static (ได้แก่ class model, generalization models, association models)
• โมเดลแบบ dynamic (ได้แก่ sequence models, state machine models)
• ต้องมีการกำหนดวิธีการใช้งานหรือการเชื่อมต่อของ object ต่างๆ อย่างแม่นยำเพื่อให้ object อื่น ๆ สามารถใช้งานมันได้
• อาจนำ UML มาใช้เพื่ออธิบาย Key points
• เมื่อพัฒนาซอฟต์แวร์ ควรพิจารณาความเป็นไปได้ที่จะนำซอฟต์แวร์ที่มีอยู่มาใช้ใหม่
• ไม่ว่าจะเป็น component, service, หรือระบบที่สมบูรณ์
• Configuration management คือกระบวนการของการจัดการการเปลี่ยนแปลงในระบบซอฟต์แวร์ที่พัฒนาขึ้น
• เป็นสิ่งสำคัญเมื่อมีทีมงานร่วมมือกันพัฒนาซอฟต์แวร์
• การพัฒนาซอฟต์แวร์ส่วนใหญ่เป็นการพัฒนาแบบ host-target development
• คุณใช้ IDE บนเครื่องโฮสต์เพื่อพัฒนาซอฟต์แวร์ จากนั้นจะถูกโอนย้ายไปยังเครื่องเป้าหมายเพื่อการใช้งาน
• การพัฒนา open source เกี่ยวข้องกับการทำให้ source code ของระบบเป็นแบบสาธารณะ
• ซึ่งหมายความว่าคนทั่วไปสามารถเสนอการเปลี่ยนแปลงและปรับปรุงซอฟต์แวร์ คำถาม???