1. 1
ชื่อไฟล์ : Introduction Software Factory
ต้นฉบับ :
นักเขียนต้นฉบับ :
ลงในฉบับ / คอลัมน์ :
โดย (หรือ เรียบเรียงโดย) : ปฐมรัตน์ ใจกว้าง (นายประกอบ พงศ์ปฏิเมธ)
บรรณาธิการ :
ชื่อเรื่อง : 1. การพัฒนาซอฟต์แวร์ด้วย Software Factory Toolkits
2. ความรู้เบื้องต้นเกี่ยวกับ Enterprise Software Architecture Development
3. ความรู้เบื้องต้นเกี่ยวกับ Software Factory
เรื่องย่อ : การพัฒนาซอฟต์แวร์ด้วยแนวคิด Software Factory เป็นแนวคิดที่ใช้ออกแบบและพัฒนาระบบงานขนาดใหญ (Enterprise
Software Development) ซึ่งจาเป็นอย่างมากที่ต้องพัฒนาโครงสร้างหลักหรือสถาปัตยกรรมซอฟต์แวร์ (เฟรมเวิร์ค) ให้ดีเสียก่อน แต่
นักพัฒนาในบ้านเราส่วนมากก็คิดพัฒนาเฟรมเวิร์คด้วยตนเอง ใครมีประสบการณ์มากก็พัฒนาได้ดี ใครมีประสบการณ์น้อยก็พัฒนาได้ไม่
ดีนัก รวมถึงความรู้ในเรื่อง Enterprise Software Architecture ของนักพัฒนาบ้านเรายังมีไม่มาก และต่างคนต่างพัฒนา ทาให้วิธีการและ
กระบวนการมีความหลายหลากและไม่สามารถแลกเปลี่ยนแนวคิดกันได้มากนัก ทาให้กระบวนการเรียนรู้ของเรามีจากัด ดังนั้นส่วนที่ผม
เสนอมานี้คือการนาแนวคิดมาตรฐานที่ทางกลุ่มพันธมิตรไมโครซอฟต์ (Microsoft Community) ได้พัฒนามาให้ใช้เพื่อใช้เป็นรูปแบบ
(Patterns) และนามาปฏิบัติได้จริง (Practices) ซึ่งก็ตรงกับชื่อกลุ่มที่เขาตั้งมาคือ Patterns & Practices นั่นเอง ดังนั้นจึงอยากเรียนเชิญ
ผู้อ่านทุกท่านลองมาทาความรู้จักเครื่องมือ รูปแบบและกระบวนการที่เขาให้มาว่ามันจะดีเพียงใด และถ้ามันดีจริง ก็อยากให้พวกเรา
ช่วยกันเรียนรู้และมาแลกเปลี่ยนความคิดกัน ผมเพียงแต่เป็นผู้นาเสนอและเริ่มต้นให้ครับ รวมทั้งยินดีตอบคาถามที่ท่านผู้อ่านสงสัยในสิ่ง
ที่ผมพอตอบได้ครับ
โปรยเปิด :
เนื้อเรื่อง :

2. 2
Enterprise Software Architecture Development กับ Software Factory
สวัสดีครับ ผมปฐมรัตน์ ใจกว้าง สาหรับครั้งนี้เป็นครั้งแรกที่ผมเขียนบทความลงบน PC Magazine แต่ก็ไม่ใช่ใหม่เสีย
ทีเดียว เพราะว่าเคยแปลหนังสือของ Microsoft Press ที่เกี่ยวกับ Windows 2000 Professional ตอนนั้นเป็นอะไรที่เหนื่อย
มาก เพราะเริ่มต้นไม่รู้จะใช้คาอะไรดี การใช้ภาษาเป็นเรื่องยากจริงๆ
มาวันนี้ไม่ได้มาแปลหนังสือ แต่มาเขียนบทความที่มาจากประสบการณ์ ทั้งที่เคยวิเคราะห์ ออกแบบระบบ และ ศึกษา
และพัฒนา (Research and Development) เทคโนโลยีใหม่ๆ ของไมโครซอฟต์มาหลายปี จนได้ไปเห็น เครื่องมือที่ใช้
พัฒนางานที่เป็นรูปแบบ มีตัวอย่างการใช้งาน ตัวอย่างระบบงานจริง ขั้นตอนและวิธีการใช้งานเป็นระบบแบบแผน รวมถึง
ตัวซอฟต์แวร์เลยทีเดียว โดยมีบริษัทไมโครซอฟต์เป็นแกนนา และมีพันธมิตรมาร่วมตั้งเป็นกลุ่มนักพัฒนาโดยใช้รูปแบบการ
พัฒนามาตรฐาน ซึ่งผมก็สนใจเข้าไปศึกษาและเรียนรู้ รู้สึกว่าน่าสนใจมาก ก็เลยอยากแนะนาสิ่งดีๆ ให้ผู้อ่านลองอ่านดูครับ
และเปิดโอกาสให้ทุกท่านวิจารณ์และแลกเปลี่ยนความคิดเห็นกันได้ ผมก็เพียงเอาประสบการณ์เล็กๆ น้อยๆ มานาเสนอ
สาหรับเครื่องมือดังกล่าวนั้น เป็นเครื่องมือที่ใช้พัฒนาระบบงานและสถาปัตยกรรมซอฟต์แวร์ขนาดใหญ่ (Enterprise
Software Development) ซึ่งผมจะเริ่มต้นจากแนวคิดของการตั้งโรงงานพัฒนาซอฟต์แวร์ (Software Factory) เพราะว่า
แนวคิดของเครื่องมือพัฒนาดังกล่าวนี้มาจากแนวคิดของโรงงานผลิตซอฟต์แวร์ (Software Factory) ซึ่งหลายท่านอาจจะ
เห็นว่าเป็นเรื่องใหญ่มาก และเร็วๆ นี้ก็มีข่าวบอกมาว่า เราจะเป็น Outsource แข่งกับ อินเดีย จีน เวียดนาม ในด้าน
Enterprise Software ก็ขอให้ทบทวนนโยบายใหม่ เรามีนักพัฒนาซอฟต์แวร์หลักหมื่น แต่เวียดนามมีแผนจะผลิตนักพัฒนา
ซอฟต์แวร์เป็นหลักล้าน เราจะทาอย่างไรดี ถ้าบทความผมมีประโยชน์ต่อการสร้างสรรค์นักพัฒนาซอฟต์แวร์เล็กๆ ผมก็ยินดี
แล้วครับ ถ้าผู้ใหญ่ของเรายอมแพ้ พวกเราจะยอมแพ้ตามหรือเปล่าครับ ผมคนหนึ่งที่ไม่ยอมแน่นอน
ก่อนอื่นเรามาเริ่มเรื่องแนวคิดของการพัฒนาระบบงานด้วย Software Factory ของเราดีกว่าครับ
แนวคิดของการพัฒนาระบบงานด้วย Software Factory
สาหรับแนวคิดในการออกแบบระบบงานนั้นจะใช้แนวคิดของโรงงานพัฒนาซอฟต์แวร์ (Software Factory) ซึ่งเป็นการ
รวบรวมองค์ความรู้สมัยใหม่แบบบูรณาการเพื่อใช้แก้ไขปัญหาและปรับปรุงกระบวนการพัฒนาซอฟต์แวร์จากการพึ่งพา
ฝีมือของนักพัฒนาไปสู่การใช้เทคโนโลยีชั้นสูงและความรู้ทางวิศวกรรมซอฟต์แวร์ที่ทันสมัยให้เหมือนกับอุตสาหกรรมการ
ผลิตประเภทอื่น เช่น อุตสาหกรรมผลิตรถยนต์ เป็นต้น โดยแนวคิดโรงงานพัฒนาซอฟต์แวร์ (Software Factory) นี้จะเน้น
การออกแบบและพัฒนาชิ้นส่วนซอฟต์แวร์ (Semi-Part) ซึ่งจะถือว่าเป็น Software Asset พร้อมที่จะนามาปรับแต่งและ
นามาประกอบกันให้เป็นชิ้นส่วนซอฟต์แวร์สาเร็จ (Finished Software Part) เพื่อนาไปใช้ประกอบกันเป็นแอพพลิเคชันอีกที
หนึ่งตัวอย่างเช่น ชิ้นส่วนหน้าจอที่ใช้บันทึกเรียกดูสินค้าคงคลังเป็นต้น ซึ่งชิ้นส่วนนี้จะแยกออกจากชิ้นส่วนเป็นบิซิเนสโลจิก
(Business Logic) และส่วนที่จัดการข้อมูล (Data Access) สาหรับชิ้นส่วนหน้าจอนั้นก็ยังสามารถแยกออกเป็นชิ้น
ส่วนย่อยๆ ได้อีกและนามาประกอบกันเป็นหน้าจอสาเร็จ (Finished Screen Part) เพื่อให้ง่ายต่อการปรับปรุงเปลี่ยนแปลง
หน้าจอให้มีความหลายหลากตามความต้องการของลูกค้าที่เปลี่ยนไป รวมไปถึงการเปลี่ยนแปลงเทคโนโลยีใหม่ในอนาคต
จากแนวความคิดโรงงานพัฒนาซอฟต์แวร์นั้น ก็เป็นที่พูดกันมานานมากทั้งในประเทศและต่างประเทศแต่ก็ยังไม่
ประสบความสาเร็จมากนักเนื่องจากขาดเทคโนโลยีสนับสนุนทาให้การพัฒนาใช้ต้นทุนสูง ซึ่งผู้ที่เริ่มใช้แนวคิดของโรงงาน
พัฒนาซอฟต์แวร์ครั้งแรกคือ บริษัท Hitachi ได้เริ่มพัฒนา Hitachi Software Factory ขึ้นมาเมื่อปี 2512 ต่อจากนั้นบริษัท
System Development ของอเมริกา ก็เริ่มใช้แนวคิดนี้ในการพัฒนาเมื่อปี พ.ศ. 2518

3. 3
จากแนวคิดดังกล่าวนั้น ในปัจจุบันนี้มีความเป็นไปได้สูงขึ้นเมื่อ Jack Greenfield และ Keith Short ซึ่งทั้งสองท่านเป็น
Architect อยู่ที่บริษัทไมโครซอฟท์ ได้เขียนหนังสือชื่อว่า “Software Factories Assembling Application with Patterns,
Models, Frameworks, and Tools” เมื่อปี พ.ศ. 2547 หลังจากนั้นปี พ.ศ. 2548-ปัจจุบัน ทางบริษัทไมโครซอฟต์ รวมถึง
กลุ่มพันธมิตรของไมโครซอฟต์ (Microsoft Community) ที่อยู่ทั่วโลก ก็ได้ผลิตเครื่องมือในการพัฒนาซอฟท์แวร์ขึ้นตาม
แนวคิดของบุคคลทั้งสองนี้โดยเริ่มต้นจาก Enterprise Library Block ซึ่งใช้เป็นมาตรฐานในการเขียนโปรแกมในเรื่องต่าง ๆ
เช่น การติดต่อฐานข้อมูล การเขียนโปรแกรมตรวจสอบความผิดพลาดของโปรแกรม การเขียน Log File เป็นต้น หลังจาก
นั้นก็ได้ออกชุดเครื่องมือ Smart Client Software Factory (SCSF) ซึ่งนับได้ว่าเป็นก้าวแรกของแนวคิด Software Factory
จากนั้นก็ได้ออก Web Service Software Factory (WSSF) ซึ่งใช้เป็นเครื่องมือหรือเครื่องจักรในการผลิตชิ้นงานที่เป็น SOA
ซึ่งเครื่องมือทั้งหมดนี้จะใช้ Guidance Automation Toolkit เป็นเครื่องมือสร้างชิ้นส่วนซอฟต์แวร์ให้โดยอัตโนมัติถ้าชิ้นส่วน
นั้นถูกพัฒนาด้วยวิธีการ รูปแบบและขั้นตอนเดียวกัน หลังจากนั้นก็ได้พัฒนา Composite Application Guidance สาหรับ
WPF และ Silverlight เพื่อใช้กับเทคโนโลยีใหม่ของไมโครซอฟต์ นั่นก็คือ WPF และ Silverlight นอกจากนั้นก็มีเครื่องมือ
อื่นๆ อีกมาก ซึ่งเครื่องมือต่างๆ นี้สามารถดาวน์โหลดมาใช้ได้โดยไม่เสียค่าใช้จ่ายใดๆ ซึ่งจะทาให้ประหยัดต้นทุนในการ
พัฒนาเครื่องมือและทาให้ระบบงานรองรับงานได้ยืดหยุ่นและมีมาตรฐานเทียบเท่าต่างประเทศได้ สาหรับรูปที่ 1 นั้นจะเป็น
สิ่งที่มาพร้อมกับเครื่องมือ
รูปที่ 1: คาแนะนามาตรฐาน (Guidance) และตัวอย่างการใช้งานของ Software Factory
จากรูปที่ 1 จะเห็นว่าชุดเครื่องมือของ Software Factory นั้นจะมี ข้อแนะนาเชิงปฏิบัติ (Recommended Practices) ซึ่งจะแบ่ง
ออกเป็นหลายๆ ด้านด้วยกัน คือ เอกสารที่อธิบายสถาปัตยกรรมการออกแบบ (Architecture Documentation) ตัวอย่าง QuickStarts

4. 4
รูปแบบมาตรฐานที่ใช้พัฒนา (Patterns) ไลบรารี และ บล็อกมาตรฐานสาหรับพัฒนาแอพพลิเคชัน (Application Blocks) เทมเพลตช่วย
การพัฒนา และ Recipes รวมถึงตัวอย่างแอพพลิเคชันจริงที่ใช้พัฒนาด้วยวิธีนี้(Reference Implementation) ซึ่งช่วยให้สามารถศึกษา
วิธีการใช้งานของเครื่องมือดังกล่าวได้เป็นอย่างดี
จากแนวความคิดเรื่องโรงงานพัฒนาซอฟต์แวร์ (Software Factory) รวมถึงเครื่องมือต่างๆ ที่บริษัทไมโครซอฟต์ได้พัฒนาขึ้นมา
ช่วยสนับสนุน ทาให้เราสามารถพัฒนาชิ้นส่วนซอฟต์แวร์ (Simi-Software Part) ได้ง่ายขึ้นด้วยวิธีการดังรูปด้านล่าง
รูปที่ 2: รูปแสดงการพัฒนาชิ้นส่วนซอฟต์แวร์
จากรูปจะเห็นว่า ส่วนที่อยู่ด้านล่างนั้นจะเป็น Fixed Assets ซึ่งเป็นชิ้นส่วนประกอบที่จะใช้ทาเป็นซอฟต์แวร์ และทาง
ฝั่งซ้ายมือ ก็เป็นกระบวนการที่เพิ่มเข้ามาคือ เราต้องมีการทา Product Line Development ซึ่งตรงนี้ก็อาจหมายถึง การ
แบ่งออกเป็น การพัฒนาหน้าจอ ส่วนเชื่อมต่อฐานข้อมูล และส่วนบิซิเนสโลจิกเป็นต้น ซึ่งเมื่อเราเตรียมเสร็จเรียบร้อยแล้ว
มันก็จะเป็น Variable Asset ที่พร้อมเข้าไปอยู่ในกระบวนการทางด้านขวามือก็คือ Product Development ซึ่งจะเป็น
กระบวนการทาให้ออกมาเป็นงานสาเร็จรูปที่พร้อมให้ทดสอบการทางานหรือให้ผู้ใช้ ใช้งานต่อไป
Automation Lifecycle Management (ALM)
ในการพัฒนาระบบงานที่เป็นโรงงานผลิตซอฟต์แวร์นั้น จาเป็นอย่างยิ่งที่ต้องใช้เครื่องจักรที่ทันสมัยเพื่อให้สามารถ
รองรับการพัฒนาที่ซับซ้อน และสอดคล้องกันทั้งกระบวนการ ตัวอย่างเช่น จากความต้องการลูกค้า (Requirements) นั้น
เป็นสิ่งแรกที่เข้ามาในกระบวนการ จากนั้นก็จะเข้าไปสู่กระบวนการวิเคราะห์ (Analysis) สร้างโมเดลการออกแบบ
(Modeling) และพัฒนา (Develop), Build, ทดสอบระบบ(Test) ซี่งทั้งหมดจะต้องทางานเป็นระบบสอดคล้องกันตั้งแต่ต้น
จนจบ และควบคุมชิ้นงานที่ออกมา ในแต่ละขั้นตอนให้สามารถตรวจสอบได้และตรงตามความต้องการของลูกค้าที่ให้มา
และกระบวนการทั้งหมดควรจะเป็นระบบอัตโนมัติให้มากที่สุดเพื่อที่จะประหยัดคนทางาน แต่ได้งานมีประสิทธิภาพสูงสุด
ดังนั้นการสร้างโรงงานพัฒนาซอฟต์แวร์จึงหลีกเลี่ยงไม่ได้ที่จะต้องใช้เครื่องจักรที่ทันสมัย ซึ่งตรงนี้ก็ตรงกับผลิตภัณฑ์ของ
ไมโครซอฟต์คือ Visual Studio Team System ซึ่งผมกาลังรอใช้เวอร์ชั่น 2010 อยู่ ซึ่งจะมีฟิเจอร์ดีๆ หลายๆ อย่าง

5. 5
รูปที่ 3: รูปแสดงกระบวนการทางานของ ALM
จากรูป เป็นแผนภาพแสดงส่วนประกอบต่างๆ ที่ทางานร่วมกันของกระบวนการพัฒนาซอฟต์แวร์ที่เป็น ALM

6. 6
สร้างโรงงานซอฟต์แวร์
สาหรับเนื้อหาในตอนนี้เราจะสร้างโรงงานกัน สาหรับโรงงานผลิตซอฟต์แวร์ (Software Factory) จะประกอบด้วยองค์ประกอบดังนี้
1. สถานที่ ผมคิดว่าถ้าเป็นไปได้ผมจะสร้างเว็บไซต์ส่วนกลางและให้สมาชิกผู้อ่านทั้งหลายที่สนใจ เข้ามามีส่วนร่วมในโรงงาน
ซอฟต์แวร์ด้วย โดยแบ่งเป็นบทบาทแต่ละบทบาทซึ่งผมจะได้อธิบายต่อไป และเราจะพัฒนาซอฟต์แวร์ต้นแบบกัน ก็อาจจะต้องมี
เรื่อง Software Development Environment เข้ามาเกี่ยวข้อง ซึ่งต่อไปจะสร้างเป็นรูปแบบใดค่อยว่ากันไป (ถ้ามันเกิดขึ้นได้) และ
ผู้ที่ทางานก็สามารถทางานอยู่ที่ใดก็ได้โดยผ่านอินเตอร์เน็ต เพื่อใช้เวลาว่างให้เป็นประโยชน์ (สาหรับท่านที่ยังมีภาระทางาน
ประจาอยู่) เพื่อที่จะได้เป็นสนามฝึกฝนในเรื่อง Enterprise Software Architecture Development
2. ทีมงาน แน่นอน โรงงานก็ต้องประกอบด้วยเจ้าของและผู้ถือหุ้น และพนักงานใช่ไหมครับ ซึ่งก็มีดังต่อไปนี้ครับ
2.1 Project Sponsor หรือผู้ให้การสนับสนุน สาหรับตรงนี้ผมว่า ทุกท่านที่ร่วมในโครงการเป็น Project Sponsor ได้ครับ
เพราะว่าอะไร ก็เพราะว่าเราทางานโดยไม่ต้องใช้เงินทุนจากคนอื่น เราทางานโดยใช้เงินทุนของพวกเรากันเอง นั่นคือเวลาที่
มาร่วมทางาน หลายคนอาจจะงงว่า เราจะทาอะไร ในตอนเริ่มต้นคงยังไม่มีอะไรมากก็คงเป็นสนามฝึกให้คนในชุมชนเข้าใจ
การทาแอพพลิเคชันแบบโรงงานซอฟต์แวร์นั่นเอง (ถ้าพวกเราเห็นด้วยนะครับ ผมแค่เสนอแนวคิดเข้าไป) แล้วต่อไปค่อยว่า
กันว่าพวกเราจะทาอะไรต่อสาหรับชุมชนเรา เนื่องจากการทาโรงงานซอฟต์แวร์ ต้องใช้ทีมงานที่มีความรู้ความสามารถ
เฉพาะด้านในเรื่องต่างๆ มาทางานร่วมกัน ภายใต้จุดมุ่งหมายเดียวกัน และด้วยกระบวนการที่ดี และทุกคนก็เป็นเจ้าของ
ร่วมกัน (ดีไหมครับ) เอ ฟังดูจะทาได้อย่างไร ก็มาร่วมออกความคิดกันก็ได้ครับ นอกจากนั้นผมอยากให้ทาง บริษัท
ไมโครซอฟต์เข้ามาสนับสนุนด้วย เพราะว่าเขาเป็นเจ้าของเทคโนโลยี และเราก็เอาเทคโนโลยีเขามาใช้ร่วมกันเป็น Total
Solution จะให้เป็นตังค์หรือให้เป็นเครื่องมือก็ได้ครับ หรือท่านสมาชิกท่านใดที่มีเงินเหลือเยอะและไม่รู้จะเอาไปทาอะไรก็
บริจากก็ได้ครับ
2.2 ทีมพัฒนา สาหรับทีมงานนั้นจะมีบทบาทและความรับผิดชอบดังรูปดังนี้ครับ
รูปที่ 4: รูปแสดงโครงสร้างของทีมงาน

7. 7
จากรูปที่ 4 เป็นรูปแสดงโครงสร้างของทีมงานซึ่งมีรายละเอียดดังต่อไปนี้
2.1.1 Project Manager (PM) ทาหน้าที่บริหารจัดการโครงการ เพื่อให้งานสาเร็จอยู่ภายในเวลาและค่าใช้จ่ายที่
กาหนด
2.1.2 Business Analyst ทาหน้าที่วิเคราะห์ความต้องการของระบบงาน ซึ่ง BA จะต้องมีความรู้ดีในเรื่อง Business
Process ของงานที่กาลังทาอยู่ซึ่งที่จริงแล้วจะต้องรู้ดีมากว่าผู้ใช้เพราะว่าผ่านงานมาหลายหลากและจะต้อง
แนะนาผู้ใช้และปรับปรุงกระบวนการทางานของผู้ใช้ได้ไม่ใช่ไปรับฟังผู้ใช้งาน และทากระบวนการตามผู้ใช้
กาหนดอย่างเดียว ถ้าเป็นอย่างนี้เราจะเรียกว่า System Analyst มือใหม่หัดขับครับ
2.1.3 Software Architect ทาหน้าที่ออกแบบโครงสร้างของระบบงาน (Framework) และจัดทารูปแบบการพัฒนา
มาตรฐาน (Patterns and Standard Guideline) และเครื่องมืออื่นๆ ให้Developer ไว้ใช้งาน ซึ่ง Software
Architect นั้นจะต้องมีความรู้ดีในเรื่อง OOAD/OOP และ Development Patterns รักเทคนิคเป็นชีวิตจิตใจ
Software Architect จะไม่ชอบไปวิเคราะห์ระบบมากนัก ทาได้ครับแต่ให้เลือกไม่เอาดีกว่า พูดแล้วเหมือน
ทานายดวงคนราีี Software Architect เลยครับ เพราะว่าผมก็คนราีีนี้เหมือนกัน (ผู้เขียนเคยเรียนวิชา
โหราีาสตร์มาแต่ไม่มีเวลาีึกษาเพิ่มเติม แค่ติดตามเทคโนโลยีให้ทันไมโครซอฟต์ก็แย่แล้ว) นอกจากนั้น
สาหรับการออกแบบที่เป็นโรงงานซอฟต์แวร์นั้น Software Architect จะคอยทาหน้าที่สร้างชิ้นงานที่เป็น
Simi-Part และกาหนดสเปกเพื่อให้สามารถนามาประกอบกัน (Assembly) ให้ได้เป็นชิ้นงานสาเร็จ รวมถึง
จัดทาคู่มือการทางานของไลน์การผลิตต่าง ๆ ฝึกอบรมการใช้งาน แก้ไขปัญหาที่เกิดขึ้นที่เกี่ยวกับงานนั้น
รวมถึงปรับปรุงกระบวนการให้ดีขึ้น
2.1.4 ต่อไปเป็น System Analyst (SA) ซึ่งทาหน้าที่เป็นนักวิเคราะห์ระบบ เก็บรวบรวมความต้องการลูกค้า จัดทา
Requirement Specification และควบคุมการเปลี่ยนแปลงความต้องการเพื่อไม่ให้กระทบกับแผนงานหลัก
มากนัก สาหรับ Software Architect นั้น (ผู้เขียนไม่รู้จะใช้ตัวย่ออะไรเนื่องจากเหมือนกับ SA ถ้าใครอยากตั้ง
ตัวย่อก็เชิญครับ) และนอกจากนั้น SA ก็จะต้องเข้ามาออกแบบระบบโดยจะต้องทางานร่วมกันกับ Software
Architect ซึ่งในส่วนตัวผมมองว่า SA จะออกแบบในเชิง High Level Design หรือในระดับภาพกว้างๆ ซึ่งยัง
ไม่ใช้เทคนิคมากนักเพื่อให้ครอบคลุมความต้องการของลูกค้าเพราะว่ารู้ความต้องการของลูกค้าได้ดีกว่า ส่วน
Software Architect นั้นจะออกแบบในเชิงรายละเอียด (Detail Level Design)โดยรับข้อมูลมาจากSA (SA
และ Software Architect อาจเป็นคนเดียวกันได้ครับเพราะผมพูดถึงบทบาท (Role) คนหนึ่งอาจทาได้หลาย
Role ครับ) และจะต้องให้ SA คอยทบทวน (Review) ว่าสิ่งที่ได้ออกแบบตอบสนองต่อความต้องการลูกค้าได้
ทั้งหมดหรือไม่ ดังนั้น SA, Software Architect และ PM จะคอยตรวจสอบการออกแบบระบบงานก่อนที่จะ
เข้าไปสู่กระบวนการผลิตจริง เพราะว่าถ้าเข้าสู่กระบวนการผลิตแล้ว มีการเปลี่ยนแปลงการออกแบบนั่นคือ
หายนะครับ เพราะว่าจะทาให้ต้นทุนสูงขึ้นอย่างมหาีาล
2.1.5 ต่อไป ก็เป็น SQA และ Test Manager ซึ่งอาจจะแยกเป็นแต่ละ Role ก็ได้โดย SQA (Software Quality
Assurance) ซึ่งถ้าใครทา CMMI อยู่ก็จะรู้ว่าไม่มีคนนี้ไม่ได้เพราะมันเป็นพื้นฐานที่สาคัญเพื่อควบคุม

8. 8
กระบวนการทางานให้เป็นไปตามที่กาหนด ซึ่ง SQA จะเป็นผู้บริหารจัดการกระบวนการทางานและ
ตรวจสอบระบบงาน รวมถึงการตรวจสอบทีมงานว่าได้ทาตามกระบวนการที่กาหนดไว้หรือไม่และจัดทา
เอกสารต่างๆ ที่จาเป็นครบถ้วนหรือไม่ พูดแล้วหลายคนจะไม่คุ้นกับคนราีีนี้ คนราีีนี้เป็นนักตรวจสอบครับ
(เอาอีกแล้ว) คอยหาว่าชาวบ้านลืมทาอะไรที่สาคัญ หรือละเลยบางอย่างไปหรือไม่ บางคนเก่งถึงขนาดมอง
แป๊ บเดียวรู้ว่าเราคีย์อะไรผิด เห็นไหมว่าเขามีความสามารถพิเีษอะไรที่เราทาไม่ได้อย่าเอาคนราีี Software
Architect ไปทาเด็ดขาดทาได้ครับแต่ต้องใช้ความพยายามสูง และโดยนิสัยแล้วไม่ชอบ สาหรับ Test
Manager รวมถึงนั้นจะเป็นผู้บริหารจัดการการทาสอบระบบงานตามแผนทดสอบ ตามเหตุการณ์ (Scenario)
โดยแบ่งออกเป็นกรณีย่อยๆ ซึ่งเราจะเรียกว่า Test Case และจัดทาขั้นตอนการทดสอบรวมถึงกาหนดลักษณะ
ข้อมูลที่สอดคล้องกับเหตุการนั้นๆ เพื่อให้คุมกรณีต่างๆ ให้มากที่สุด รวมถึงกรณีแปลกๆ ที่จะเกิดขึ้นด้วย
ส่วนผู้ที่ทาการทดสอบนั้นจะเป็น Tester ครับ
2.1.6 สาหรับ Developer นั้นจะทาหน้าที่พัฒนางานตามสเปกที่ได้ออกแบบมาจาก SA โดยโครงสร้างแล้วกลุ่ม
Developer จะถูกแบ่งออกเป็นกลุ่มย่อย ๆ ซึ่งในภาษาโรงงานจะเรียกว่าไลน์การผลิตนั่นเอง อ้อลืมไป ในส่วน
Software Architect นั้นก็จะแบ่งออกเป็นกลุ่มๆ เหมือนกันคือหัวหน้าทีมดูแลทั้งหมด และทีมต่าง ๆ ที่ทา
หน้าที่ออกแบบส่วนต่าง ๆ (โดยธรรมชาติแล้ว Software Architect ในกลุ่มต่าง ๆ ก็เติมโตมาจาก Developer
นั่นเอง) และการแบ่งออกเป็นกลุ่มๆ นี้ในทางปฏิบัติเป็นเรื่องที่ทาได้ไม่ยากแล้วครับมีเครื่องมือสนับสนุน
(ไม่ใช่ว่าผมจะเอาแนวคิดสวยหรูมาแสดงให้ดูเท่ แต่มันปฏิบ้ติได้จริงซึ่งผมจะได้อธิบายต่อไป) โดยจะ
แบ่งเป็นกลุ่มๆ ดังนี้
2.1.6.1 นักพัฒนาวิีวกรรมหน้าจอ (Screen Engineer) ซึ่งการพัฒนาหน้าจอนี้ในปัจจุบันนับว่าเป็นงานที่มี
ความซับซ้อนมาก และผู้ใช้จะยอมรับระบบหรือไม่ก็อยู่ที่หน้าจอนี้ โดยเฉพาะหน้าจอที่ใช้เทคโน
โลยี WPF และ Silverlight
2.1.6.2 นักพัฒนาบิซิเนสโลจิก (Business Logic Engineer) สาหรับนักพัฒนาส่วนนี้ผมเคยคิดว่าจะให้ SA
เป็นคนทา เนื่องจากว่า SA จะรู้ดี และสามารถเขียนได้ดีโดยที่ไม่ต้องถ่ายทอดสเปกไปให้
Developer ซึ่งแน่นอน Developer ก็จะไม่สามารถรับได้100% ขึ้นอยู่กับ Developer ว่ามี
ประสบการณ์มากน้อยเท่าไร สมมุติว่ารับได้70% อีก 30% ก็จะเป็นข้อบกพร่องของซอฟต์แวร์
(Bug) ครับ ซึ่งการพัฒนาตรงนี้ผมมองว่าเราควรเอาเทคนิคของ Windows Workflow Foundation
(WF) หรือเครื่องมือที่ใช้พัฒนา Workflow หรือ Business Process Management (BPM) มาใช้
เพราะว่า SA ก็ต้องเขียนสเปกเป็นโฟลว์อยู่แล้ว ทาไมไม่เขียนโดยใช้เครื่องมือที่เป็น Workflow เลย
สาหรับส่วนที่เป็นโปรเซสย่อยของการทางานในโฟลว์นั้น (จะเรียกว่า Activity Code) ก็ให้
Developer เป็นผู้พัฒนา อย่างน้อยโฟลว์ก็ไม่ผิด ตรงนี้เราสามารถออกแบบการทางานให้ดีได้
นอกจากนั้นแล้ว ถ้าเป็นงานที่เป็นเซอร์วิส ก็พัฒนาให้เป็น SOA ได้ซึ่งก็มีเครื่องมือ Web Services
Software Factory หรือเครื่องมืออื่นๆ ช่วยอยู่แล้ว ดังนั้นเรื่อง SOA ก็เป็นเรื่องที่มีความซับซ้อนอยู่
แล้วก็อาจจะแยกเป็นเรื่องหนึ่งซึ่งจะเอาไปต่อกับ Workflow ได้(WF 4.0 สามารถ integrated กับ

9. 9
WCF ได้ดีแล้วครับ ตรงนี้นับว่าเป็นข่าวดีสาหรับผู้ที่จะทา Workflow ให้เป็น SOA) โครสนใจก็มา
ีึกษาตรงนี้ได้
2.1.6.3 สาหรับฐานข้อมูลนั้นเป็นหน้าที่ของ Data Administrator (เป็นคนเดียวกับ SA ก็ได้ครับ) ดูแล
ข้อมูล ความสัมพันธ์ข้อมูลเพื่อสร้างฐานข้อมูล และจัดทา Data Model สาหรับ Data Model นี้
ผู้เขียนได้ใช้ADO.NET Entity Framework (EF) สาหรับทา Data Model ซึ่งก็จะทาให้นักพัฒนา
สามารถเรียกใช้Business Entity ที่ถูกสร้างมาจากโมเดลได้โดยที่ Develop ไม่ต้องไปสร้างเอง ซึ่ง
การสร้าง Data Model และ Entity Class ส่วนกลางเป็นหน้าที่ของ Data Administrator ที่สร้างไว้
ให้Developer ใช้งานเพื่อให้สามารถพัฒนางานส่วนนี้ได้ง่ายที่สุด
3 แนวคิด เทคโนโลยีและเครื่องมือที่นามาใช้
ต่อไปก็จะพูดเรื่องเทคโนโลยีและเครื่องมือที่จะนามาใช้ครับ ว่าโรงงานเราจะนาเครื่องจักรอะไรมาช่วยผลิตซอฟต์แวร์ให้ทันสมัย
ซึ่งก็มีเป้าหมายคือ ลดต้นทุนการทางาน (รวมต้นทุนที่เกิดจาการบารุงรักษาซอฟต์แวร์ด้วย) เพิ่มคุณภาพของซอฟต์แวร์ให้ดีขึ้น ซึ่ง
จริงๆ แล้วจะต้องมีกระบวนการพัฒนาซอฟต์แวร์หรือ Software Process Improvement ร่วมด้วยนะครับ การใช้อย่างใดอย่าง
หนึ่งไม่สามารถบรรลุเป้าหมายได้เห็นไหมครับการพัฒนาซอฟต์แวร์ปัจจุบันทาไมเรื่องมากจัง ก็ลองจินตนาการโรงงานผลิต
รถยนต์ก็แล้วกัน ผมว่าโรงงานผลิตรถยนต์ยังมีความซับซ้อนกว่าโรงงานผลิตซอฟต์แวร์ตอนนี้เสียด้วยซ้า
3.1 แนวคิดและเทคโนโลยี่ที่นามาใช้
สาหรับแนวคิดที่จะนามาใช้ผมก็ขอเสนอแนวคิดที่มาจากหนังสือ“Software Factories Assembling Application with
Patterns, Models, Frameworks, and Tools” เขียนโดย Jack Greenfield และ Keith Short ปี 2547 ซึ่งอธิบายแนวคิดที่
ใช้พัฒนา Software Factory ได้อย่างดี แต่ไม่ใช่ว่าเราจะไปนั่งอ่านหนังสือทั้งเล่มก่อนแล้วถึงจะมาทา เพียงแต่เราเข้าไปดู
แนวคิดเบื้องต้นเพื่อนามาปรับใช้งาน และหลังจากนั้นก็มีหนังสือชื่อ Practical Software Factories in .NET ซึ่งเขียนโดย
Gunther Lenz และ Wojtek Kozaczynski ปี 2549 และหนังสือชื่อ Programming Microsoft Composite UI Application
Block and Smart Client Software Factory ของ David S. Platt ปี 2551 ซึ่ง Platt นั้นเป็นที่ปรึกษา นักเขียน และผู้สอนอยู่
ที่ Harvard University และได้เปิดหลักสูตรการสอนเรื่อง Smart Client Software Factory ทั้งในยุโรปและอเมริกา (ผู้เรียน
ต้องเสียค่าเครื่องบินและค่าโรงแรมไปเรียนด้วยนะครับซึ่งยังไม่รวมค่าลงทะเบียนเรียน) เห็นไหมว่าในยุโรปและอเมริกา
เขาตืนตัวในเรื่องนี้แค่ไหน และพวกเราละ ถ้าตกรถไฟขบวนนี้เราอาจจะล้าหลังประเทีอื่นๆ ชนิดไล่เท่าไรก็ไม่ทัน สาหรับ
แนวคิดในด้านต่างๆ ก็จะมีดังนี้ครับ
1. แนวคิดในการออกแบบโรงงานพัฒนาซอฟต์แวร์ (Software Factory) โดยใช้Guidance และชุดเครื่องมือพัฒนา Smart
Client Software Factory สาหรับใช้พัฒนาระบบงานที่เป็นวินโดว์ฟอร์ม และ Composite Application Guidance
สาหรับ WPF และ Silverlight ซึ่งเป็น Guidance และชุดเครื่องมือที่ใช้ช่วยพัฒนา (มาพร้อมกับ .DLL สาหรับควบคุม
การทางานของ WPF และ Silverlight) และควบคุมการพัฒนาหน้าจอให้เป็นชิ้นส่วนที่ต้องการและนามาประกอบกันให้
เองโดยอัตโนมัติ (Composite UI Guidance Asset) ใช้สาหรับพัฒนาแอพพลิเคชันที่เป็น Windows Presentation
Foundation (WPF) และ Silverlight โดยใช้เฟรมเวิร์คร่วมกัน รวมถึงมี Guideline ที่จะบอกว่า ถ้าเราจะเปลี่ยน

10. 10
Code ของหน้าจอที่เป็น WPF ให้เป็น Silverlight จะต้องระวังอะไรบ้างโดยแก้ไข Code ไม่มาก ในอดีตลองนึกภาพว่า
ถ้าเราจะเปลี่ยนหน้าจอที่เป็น Windows Form ให้เป็น Web Form คุณจะต้องพัฒนาทั้งหมด แต่ในเฟรมเวิร์คใหม่นี้
คุณสามารถเปลี่ยน Code ไม่มาก แต่ผมว่าเราจะต้องวางรูปแบบก่อนล่วงหน้าเพื่อให้ง่ายต่อการเปลี่ยนหน้าจอจาก WPF
ไปเป็น Silverlight ให้ได้ง่ายมากขึ้นและสามารถควบคุมได้ตรงนี้คงฝากผู้เชี่ยวชาญทางด้านนี้ช่วยเหลือครับ (ถ้าใครที่
ชอบอะไรที่สวยๆ งามๆ)
รูปที่ 5: Composite Application Library Package
จากรูปเป็น Composite Application Library Package ซึ่งในส่วนด้านบนสุดจะเป็น Application ที่เราพัฒนาอยู่
รวมถึงเฟรมเวิร์คและโครงสร้างพื้นฐาน (Infrastructure) รวมถึงโมดูลต่าง ๆ ที่เราพัฒนาซึ่งจะใช้เฟรมเวิร์คร่วมกัน ส่วน
Library ที่อยู่ใน Patterns & Practices นั้นก็จะมี Library ต่าง ๆ ให้เราใช้งาน ส่วนการใช้งานอย่างไรนั้น ใน
Guidance จะบอกรายละเอียดรวมถึงตัวอย่างการใช้งาน ซึ่งเป็นหน้าที่เราที่จะเข้าไปศึกษาและนามาใช้หลังจากนั้น
มันก็จะเป็นมาตรฐานการทางานและการพัฒนาของเราโดยอัตโนมัติ ถ้าเราใช้ Library เหล่านี้ร่วมกันในกลุ่มของพวก
เรา มันก็จะเป็นมาตรฐานการใช้งานร่วมกัน ซึ่งจะทาให้เราสามารถเขียนโปรแกรมด้วยสไตล์เดียวกัน ผมว่าทาได้แค่นี้ก็
ได้ประโยชน์มาหาศาลแล้วครับ ท่านลองคิดเล่นๆ ต่อไปว่ามันจะเกิดประโยชน์ต่อเนื่องอะไรอีกครับ ตรงนี้ผมขอยังไม่
ขอพูดครับ

11. 11
รูปที่ 6: Patterns ที่อยู่ใน Composite Application Library
สาหรับรูปนี้เป็นรูปแบบมาตรฐาน (Patterns) ที่อยู่ใน Composite Application Library ซึ่งมี Patterns ต่าง ๆ ที่ถูกสร้าง
ขึ้นใน Composite Application Library ซึ่งมีมาทั้ง Source Code ให้เราได้ศึกษาวิธีการเขียนโปรแกรมได้ด้วย
2. การบริหารจัดการการพัฒนาซอฟต์แวร์ให้เป็นระบบอัตโนมัติ (Automation Lifecycle Management) หรือ ALM เป็น
การควบคุมขั้นตอนการพัฒนาซอฟต์แวร์โดยใช้เครื่องมือช่วยเพื่อให้กระบวนการพัฒนาซอฟต์แวร์มีประสิทธิภาพมาก
ขึ้นซึ่งก็จะใช้ Visual Studio Team System 2008 หรือ 2010 ซึ่งจะใช้ฟังก์ชันของ Project Management, Source
Control, Build Server, Testing, Bug Tracking, Deployment ส่วนการบารุงรักษาระบบงานก็น่าจะใช้การทา
Branching และ Merging รวมถึงทา Release, Service Pack คล้ายๆ กับที่ไมโครซอฟต์เขาทากัน ในกรณีที่ Build
ระบบงานให้กับลูกค้าแต่ละรายที่มีความต้องการเฉพาะ ควรจะต้องออกแบบเพื่อเตรียมรองรับไว้ล่วงหน้าซึ่งตรงนี้อาจจะ
ต้องพึ่งพาผู้เชี่ยวชาญ
3. Application Architecture Guide 2.0 Designing Application on .NET Platform เป็น Best Practice ที่ช่วย
แนะนาวิธีการพัฒนาระบบงานขนาดใหญ่ ซึ่งผู้อ่านเข้าไปดูได้ที่ http://apparchguide.codeplex.com/
4. Standard Pattern Development เป็นรูปแบบมาตรฐานที่ทั่วโลกยอมรับแล้วว่าสามารถนามาใช้แก้ไขปัญหาการ
พัฒนาซอฟต์แวร์ได้เป็นอย่างดี ซึ่ง Composite Application Guidance สาหรับ WPF และ Silverlight ก็ถูกพัฒนา
อยู่บน Standard Pattern Development ต่างๆ เช่น Dependency Injection, Inversion of Control, Service
Locator, Presentation Model เป็นต้น ซึ่งทาให้ทีมงานพัฒนาโครงสร้างได้เรียนรู้รูปแบบการพัฒนามาตรฐาน
ดังกล่าวในขณะที่ีึกษาเครื่องมือนี้ และทาให้ทีมงานสามารถพัฒนาความรู้ทางด้าน Software Architecture ได้ใน
เวลาเดียวกัน

12. 12

13. 13
3.2 เครื่องมือที่ใช้ออกแบบและพัฒนา (Design and Development Tools)
สาหรับเครื่องมือที่ใช้พัฒนาแอพพลิเคชันที่เป็นโรงงานซอฟต์แวร์นั้นผมก็ขอบอกว่าเป็นค่ายของไมโครซอฟต์ทั้งหมด ไม่ใช่ผม
รังเกียจค่ายอื่นนะครับ แต่ว่าประสบการณ์ทั้งชีวิตของผมอยู่กับไมโครซอฟต์เทคโนโลยี ส่วนเพื่อนๆ ผมรุ่นเดียวกันไปเป็น
ผู้บริหารระดับสูงกันหมดแล้ว เหลือผมนี่แหละที่ยังติดตามเทคโนโลยีอยู่แต่ก็อยากเรียนเชิญนักพัฒนาค่ายอื่นลองมาดูแนวคิด
และนาไปปรับปรุงงานของตนเอง มันได้แนวคิดในเรื่อง Architecture Design ที่ดีครับ สาหรับชุดเครื่องมือก็มีดังนี้
1. Visual Studio Team System 2008 หรือ Visual Studio Team System 2010 สาหรับเป็น Integrate
Development Environment และ Testing Tools
2. Windows 2008 Server Standard Edition หรือ Enterprise Edition ใช้เป็นเฟรตฟอร์มที่เราพัฒนา
3. Microsoft SQL Server 2008 Express Edition, Standard Edition หรือ Enterprise Edition เป็นระบบจัดการ
ฐานข้อมูล
4. Windows SharePoint Service 3.0 หรือ MOSS 2007 สาหรับพัฒนางานที่เป็น Document หรือ Content
Management รวมถึงใช้เป็นเครื่องมือที่ช่วยจัดการ Configuration Management
5. Windows Workflow Foundation สาหรับพัฒนางานที่เป็น Workflow
6. Windows Form, WPF และ Silverlight เทคโนโลยีสาหรับพัฒนาหน้าจอ
7. สาหรับ Client Platforms นั้นเพื่อความทันสมัยเราก็อาจจะใช้บน Windows 7 เลย ส่วนอื่นๆ จะเป็น Mobile
Application และอื่นๆ ก็เชิญคนที่เชี่ยวชาญด้านนั้นเข้ามาร่วมได้เลยครับ
ผมว่าแค่นี้ก็แย่แล้ว

14. 14
4 สภาพแวดล้อมของการพัฒนา (Development Environment)
รูปที่ 7: รูปแสดงสภาพแวดล้อมของการพัฒนา
สาหรับสภาพแวดล้อมของการพัฒนานั้นก็จะเป็นในลักษณะดังในรูปด้านบน ซึ่งผมได้ทาเป็น Environment Development ที่ใช้
พัฒนางานอยู่ในขณะนี้โดยเฉพาะ Project Server 2007 ที่ใช้บริหารจัดการโครงการขนาดใหญ่ ในกรณีที่เรามีโครงการมากๆ
ทาให้การบริหารจัดการทรัพยากรทาได้ดี การบริหารจัดการโครงการทาผ่าน Project Web Access โดยไม่จาเป็นต้องใช้กระดาษ
เลย สาหรับเรื่อง Development Environment นั้นประกอบด้วยส่วนต่างๆ ดังต่อไปนี้
1. เครื่องที่เป็นโดเมนคอนโทรลเลอร์ ทาหน้าที่เก็บ Active Directory ของผู้ใช้งานระบบ
2. เครื่องที่เป็น Database Server และ SharePoint Server จะติดตั้ง Microsoft SQL Server 2008 และ Windows
SharePoint Service 3.0 (WSS 3.0) และ Microsoft Search Server 2008 Express Edition ถ้าเราจะใช้SharePoint เป็น
ส่วนหนึ่งของการพัฒนาระบบ ซึ่ง WSS 3.0 และ Microsoft Search Server 2008 Express Edition นั้นไม่เสียตังค์หรือจะ
ใช้Microsoft Office SharePoint Server 2007 (MOSS 2007) ก็ได้ครับ ถ้าคุณต้องการความหรู
3. เครื่องที่เป็น Project Management Server จะถูกติดตั้ง Windows 2008 Server Enterprise Edition, Microsoft SQL
Server 2008 Enterprise Edition, WSS 3.0 หรือ MOSS 2007 , Microsoft Project Server 2007 เป็นเครื่องมือที่ใช้บริหาร
จัดการโครงการในระดับ High Level สาหรับทา Enterprise Project Management
5 การบริหารจัดการโครงการ
วิธีและกระบวนการทางาน (Methodology and Project Management Process)
สาหรับการบริหารโครงการนั้น นอกจากเราจะใช้วิธีบริหารโครงการในรูปแบบ MSF for Agile Software Development เป็นแนวทาง
ในการทางาน รวมทั้ง Project Planning, Project Monitoring and Control ที่อยู่ใน CMMI มาช่วยกระบวนการทางาน โดย
เป้าหมายหลักคือให้ซอฟต์แวร์ออกมาสู่ตลาดให้เร็วที่สุด และจะต้องมีคุณภาพดี

15. 15
6 Software Process Improvement นอกจากนั้น เราควรจะมี Software Process Improvement กระบวนการพัฒนา
ซอฟต์แวร์ที่ดี และพัฒนาให้ดีขึ้นเรื่อยๆ (ไม่มีคาว่าดีที่สุด มีแต่คาว่าดีกว่า และดีกว่า) ในด้านต่างๆ ตามกระบวนการของ CMMI หรือ
เราจะใช้Agile ก็ได้ขึ้นอยู่กับทีมงาน เพื่อรับประกันว่าซอฟต์แวร์ที่เราพัฒนานั้นมีคุณภาพ ตรงนี้เป็นเรื่องใหญ่ครับ ส่วนผมตอนนี้
ทางานอยู่ใน Committee ของ Thailand SPIN ในส่วน Project Management ซึ่งกาลังเผยแพร่ความรู้ในเรื่อง Process
Improvement ให้กับ Community อยู่เหมือนกันครับ
ถึงแม้ว่าการสร้างโรงงานผลิตซอฟต์แวร์จะประกอบด้วยส่วนต่าง ๆ มากมายก็ตาม แต่เราพยายามมองภาพรวมให้ได้ก่อน และสร้าง
ความสัมพันธ์ในส่วนต่าง ๆ ให้สอดคล้องกัน หาผู้เชี่ยวชาญทางด้านต่าง ๆ มาทางานร่วมกันตามบทบาทที่แต่ละท่านถนัด และทา
ตามบทบาทนั้น ผมว่าในลาดับแรกเป็นการทาความเข้าใจก่อนครับ เมื่อเข้าใจแนวคิดและเครื่องมือต่าง ๆ ได้แล้ว มันก็จะเริ่มง่ายขึ้น
ผมว่าทุกคนทาได้ครับ

16. 16
Software Factory Toolkits Overview
สมมุติว่าตอนนี้เราได้เริ่มตั้งโรงงานซอฟต์แวร์แล้ว ซึ่งต่อไปถ้าจะตั้งโรงงานจริงๆ รายละเอียดของการตั้งโรงงานอาจจะมีการเปลี่ยนแปลง
ตามความเหมาะสมของสภาพแวดล้อมและปัจจัยอื่น ๆ ผู้อ่านทุกท่านอยากเห็นความสาเร็จของโรงงานดังกล่าวหรือไม่ครับ ถ้าอยากเห็นก็
มาร่วมสร้างด้วยกัน ผมเชื่อมั่นว่ามันสามารถทาได้จริงในทางปฏิบัติ ดังนั้นบันไดขั้นแรกก็คือการเข้าไปรู้จักเครื่องมือของ Software
Factory Toolkits รวมถึงกระบวนการผลิตตาม Role ต่าง ๆ และขอให้สมาชิกทุกท่านที่สนใจเลือก Role ที่ตนชอบไว้ก็แล้วกัน แต่ใครจะ
สนใจมากว่าหนึ่ง Role ก็ได้ครับ
ตอนนี้สมมุติว่าเราได้ตั้งโรงงานแล้วนะครับ ดังในรูปด้านล่าง ต่อไปเราจะได้เรียนรู้เครื่องมือในการผลิตซอฟต์แวร์กันครับ
รูปที่ 8: รูปแสดงโรงงานผลิตซอฟต์แวร์
ก่อนจะลงในรายละเอียด ก็จะขอเกริ่นที่มาที่ไปของเครื่องมือหน่อยครับ Software Factory Toolkits (ลองคิดว่ามันคล้าย ๆ กับเราซื้อชุดคิ
ตของวิทยุมาต่อใช้งานเองซึ่งผู้เขียนเคยต่อเองในสมัยเด็กๆ มันทาให้เห็นภาพของการนาชิ้นส่วนซอฟต์แวร์มาต่อกันและได้เป็นแอพพลิเค
ชันสาเร็จ) ซึ่งต่อไปอาจจะมีการทา Software Application Toolkits เอาไว้ให้ผู้อ่านมาหัดต่อเล่นกันครับ
สาหรับจุดเริ่มต้นของ Software Factory Toolkits นั้นเริ่มมาจาก Microsoft Community (เดิมอยู่ในส่วนของ Patterns & Practices แต่
ปัจจุบันอยู่ในส่วนของ http:www.codeplex.com) ได้ออกเครื่องมือที่ชื่อ Enterprise Library Block (EntLib) ขึ้นมาเมื่อปี พ.ศ. 2547
(ตอนนี้เวอร์ชั่นล่าสุดเป็น 4.1 ครับ) ซึ่งเป็นเครื่องมือใช้ช่วยแนะนาวิธีการเขียนโปรแกรมให้เป็นมาตรฐานแก่นักพัฒนาในด้านต่าง ๆ เช่น
การเขียน Logging Application Block, Data Access Application Block, Security Application Block, Exception Block และอื่น ๆ
ซึ่งผู้เขียนจะไม่ลงรายละเอียดตอนนี้ซึ่งปัจจุบันนี้มันรวมอยู่ในเครื่องมือพื้นฐานที่อยู่ในชุด Software Factory Toolkits หรือเป็น Engine
Tools ซึ่งจะถูกเรียกใช้งานผ่านทางเครื่องมืออื่นๆ เช่น Smart Client Software Factory หรือ Composite Application Library นั่นเอง ซึ่ง
ก็จะซ่อนความซับซ้อนของการใช้งานของ EntLib เอาไว้ภายใน

17. 17
ต่อจากนั้น Patterns & Practices ก็ได้ออก Composite UI Application Block (CAB 1.0) ซึ่งถูกออกแบบมาเพื่อแยกส่วนที่ใช้แสดงผล
หน้าจอออกมาโปรเจ็กต์แยกต่างหาก และให้ชื่อว่า Shell
รูปที่ 9: หน้าจอแสดงส่วนประกอบของ Composite UI
จากรูปด้านบนจะแสดงให้เห็นส่วนประกอบต่างๆ ที่ CAB 1.0 ออกแบบมา ซึ่งส่วนประกอบดังกล่าวนั้นจะถูกนาไปใช้โดยกลไกการทางาน
ที่อยู่เบื้องหลัง (CAB Engine) ซึ่งกลไกการทางานเบื้องหลังผมยังไม่อธิบายตอนนี้สาหรับตรงนี้จะพูดถึงส่วนประกอบของ CAB 1.0
เสียก่อน ซึ่งจะเห็นว่าแอพพลิเคชันถูกแบ่งออกเป็นสองส่วนคือ Shell Application (ซึ่งเป็นโปรเจ็กต์หนึ่ง) และ Module ซึ่งก็เป็นโปรเจ็กต์
อีกโปรเจ็กต์หนึ่ง สาหรับในส่วนที่เป็น Shell Application นั้นก็เปรียบเสมือนเครื่องฉายภาพซึ่งจะทาหน้าที่รับภาพมาแสดงผลเท่านั้น จาก
รูปจะเห็นว่าในโปรเจ็กต์ Shell Application นั้นจะมี Shell Form ซึ่งจะมี SplitContainer ทาหน้าที่แบ่งแยกหน้าจอออกเป็น 2 ส่วน คือ
ส่วนทางซ้าย (Left Workspace) และส่วนทางขวา (Right Workspace) ซึ่งในส่วน LeftWorkspace นั้นจะมี TabbedWorkSpace บรรจุ
อยู่ภายใน (สาหรับ CAB 2.0 นั้นเขาใช้ Region แทน คาว่า Workspace ครับ) ซึ่ง Shell Application นั้นจะเรียกสั้น ๆ ว่า Shell นั่นเอง
หลายคนคงจะสงสัยแล้วว่า แล้วหน้าจอหายไปไหนละ คอยติดตามไปครับ
ต่อไปผมจะยกตัวอย่างการพัฒนาระบบงานแบบปกติที่เราพัฒนากัน โดยปกติแล้วนักพัฒนาจะนิยมเขียนส่วนที่เป็น Presentation Layer
แยกออกมาเป็นกลุ่มๆ และแต่ละกลุ่มก็จะมีโปรแกรมในส่วนหน้าจอก็จะอยู่ในโปรเจ็กต์ Presentation ดังในรูปต่อไปนี้ซึ่งเป็นที่รวบรวม
หน้าจอหรือ Windows Form ของโมดูลหนึ่ง ซึ่งในตัวอย่างนี้จะมี 3 หน้าจอด้วยกัน

18. 18
รูปที่ 10: รูปแสดงหน้าจอในโครงสร้างแบบง่าย
จากรูปจะเห็นว่าถ้าเรามีหน้าจอสามหน้าจอ เราก็จะมี Windows Form 3 ฟอร์มดังในรูป ซึ่งข้อดีของมันก็คือพัฒนาง่ายไม่ยุ่งยาก
ซับซ้อนถ้ามีการแก้ไขฟอร์มก็แก้ไขไปบนฟอร์มได้เลย (ยังไม่ต้องคิดว่ามีชั้นติดต่อฐานข้อมูลหรือชั้นบิซิเนสโลจิก คิดว่ามีอยู่ชั้นเดียวก่อนคือ
Presentation Layer) ส่วนข้อเสียคือ ถ้าบางส่วนของหน้าจอทั้งสามหน้าจอมีบางส่วนที่เหมือนกัน ก็จาเป็นต้องพัฒนาส่วนที่เหมือนกันนั้น
ทั้งสามหน้าจอทาให้ต้องพัฒนางานซ้าซ้อน แต่อย่างไรก็เหมาะกับระบบงานเล็กๆ แต่ถ้าเป็นงานที่เป็น Enterprise Application นั้นจะมี
ผลมากหรือน้อยขึ้นอยู่กับขนาดของแอพพลิเคชัน ถ้าขนาดของแอพพลิเคชันใหญ่มากก็จะมีผลกระทบมากครับ
ต่อไปมาดูว่าเฟรมเวิร์คของ CAB 1.0 นั้นมันมีดีอะไร ขอให้ท่านผู้อ่านดูรูปต่อไปครับ

19. 19
รูปที่ 11: รูปโครงสร้างระบบงานตัวอย่างที่ใช้เฟรมเวิร์ค CAB 1.0
สาหรับรูปนี้ผมได้พัฒนาให้กับหน่วยงานราชการแห่งหนึ่ง ซึ่งเป็นระบบงานจริงโดยใช้ Smart Client Software Factory ซึ่งใช้
CAB 1.0 เป็นเฟรมเวิร์คพัฒนาหน้าจอ ซึ่งในโครงสร้างของระบบงานนั้นจะมี ส่วนที่เป็น Infrastructure ของระบบงานทาหน้าที่เตรียม
ส่วนประกอบพื้นฐาน (ซึ่งรายละเอียดจะค่อยๆ เล่าให้ฟังต่อไปครับ) ซึ่งหนึ่งในนั้นก็คือ Shell Project อย่างที่ผมเคยพูดว่ามั้นเป็นส่วนที่ใช้
แสดงผลของหน้าจอที่ถูกส่งมาจากโมดูลต่าง ๆ ของระบบงาน และจะมี ShellForm ซึ่งเป็น Windows Form เพียงฟอร์มเดียวในระบบงาน
นี้ท่านผู้อ่านคงจะเห็นส่วนที่เป็น RID_F00, RID_F10 … ส่วนนี้เป็นโมดูลต่าง ๆ ครับ จะเห็นว่าโมดูลของแอพพลิเคชันถูกแยกออกมาจาก
ส่วนที่เป็น Infrastructure อย่างเด็ดขาด (Module Independence) ซึ่งในเรื่องนี้ผมจะพูดในรายละเอียดต่อไปเพราะว่ามันสาคัญกับการ
ทาโรงงานซอฟต์แวร์มาก ภายในโมดูลมีอะไรลองดูรูปถัดไปครับ

20. 20
รูปที่ 12: รูปแสดงโครงสร้างภายในโมดูล RID_F10
สาหรับในรูปนี้จะเห็นว่าภายในโครงสร้างของโมดูล RID_F10 ยังแบ่งออกเป็นโปรเจ็กต์ FID_F11 ซึงเป็นระบบงานย่อยภายใน
มูล RID_F10 ภายในโปรเจ็กต์นี้ให้ดูส่วนที่เป็น Views ซึ่งในส่วนนี้ก็จะเป็นหน้าจอต่าง ๆ นั้นเอง ซึ่งลองมาดูโครงสร้างหน้าจอที่ชื่อว่า
vwF11U0301 ซึ่งมาจาก View ของโมดูล F11 ของยูสเคซ U0301 นั่นเอง ซึ่งถ้าดูไฟล์ก็มีดังนี้
1. vwF110301.cs นั้นเป็นส่วนแสดงผลนั่นเอง แต่มันไม่ใช่ Windows Form มันเป็น User Control ครับ เห็นไหมว่า ในส่วนที่เป็น
ส่วนแสดงผลนั้นไม่มี Windows Form เลย
2. vwF11U0301Presenter.cs นั้นเป็น Presenter ไฟล์มันคืออะไรเดี๋ยวว่ากัน
3. IvwF11U0301.cs นั้นเป็นอินเตอร์เฟซไฟล์ของหน้าจอ
ดังนั้นส่วนแสดงผลนี้จะใช้ Model View Presenter (MVP) Pattern ครับ ซึ่งเขียนได้ดังนี้
รูปที่ 13: รูปแสดง MVP Pattern
จากรูปเริ่มจาก View จะเห็นว่ามีเครื่องหมายยื่นออกมาสองขาคือ ขาหนึ่งมีจุดกลม นั่นคือเครื่องหมายของอินเตอร์เฟซ ซึ่งแสดงว่า View
มีอินเตอร์เฟซโผล่ออกมาให้คลาส Presenter ติดต่อภายใน View โดยผ่านทางอินเตอร์เฟซ
เมื่อถึงตรงนี้ก็คงเห็นแล้วว่า ส่วนที่แสดงผลหน้าจออยู่ตรงไหน แต่ว่าท่านก็คงสงสัยว่า แล้วมันจะนาออกไปแสดงใน Shell ได้อย่างไร ตรงนี้
ไม่ต้องเป็นห่วงครับ เพราะ CAB มีกลไกที่นามันไปแสดงให้อยู่แล้วโดยคอมโพแน็นซ์ที่จัดเตรียมไว้ โดยมอบหมายงานให้คลาส

21. 21
ModuleController เป็นตัวทาหน้าที่เรียกใช้ โดยเขียนคาสั่งเข้าไปใน ModuleController ตามที่กาหนดเท่านั้น ซึ่งรายละเอียดผมจะพูดถึง
ต่อไปครับ ตรงนี้ให้ท่านผู้อ่านเข้าใจวิธีการทางานของ CAB เท่านั้นว่ามันคืออะไร
จากเรื่องที่พูดมานั้นเป็นเรื่อง Composite UI แต่ยังมีอีกย่างหนึ่งของ CAB คือโมดูลแต่ละโมดูลที่ออกแบบ ซึ่งจะมีความเป็นอิสระซึ่งกัน
และกัน และติดต่อสื่อสารกัน (โมดูลหนึ่งเรียกใช้งาน เช่น สอบถามข้อมูล ไปยังอีกโมดูลหนึ่ง) โดยผ่านทางกลไปพิเศษ (Event Broker
Pattern) ซึ่งเป็นรูปแบบการติดต่อสื่อสารเพื่อให้โมดูลต่าง ๆ มีความอิสระซึ่งกันและกัน เอ… คาว่าอิสระซึ่งกันและกัน (Module
Independent) หมายความว่าอย่างไร ก็หมายความว่า ถ้ามีงานโมดูล A ให้นักพัฒนานั่งอยู่ประเทศหนึ่ง และก็มีงานโมดูล B กับ
นักพัฒนาที่ทางานอยู่อีกประเทศหนึ่งโดยที่นักพัฒนาทั้งสองกลุ่มไม่ต้องรู้จักกันและต้องพูดคุยกันเลย ก็ทางานได้ครับ Software
Architect ที่ควบคุมดูแลโครงการก็เพียงแต่นาซอฟต์แวร์ทั้งสองโมดูลมาใส่ในโครงสร้างหลัก มันก็จะต่อให้เองโดยอัตโนมัติ ซึ่งเฟรมเวิร์ค
และกลไกการทางานของ CAB (ซึ่งมันถูกพัฒนาอยู่บน Pattern ต่าง ๆ) เป็นผู้จัดการให้ครับ มหัศจรรย์ไหมครับ สาหรับ CAB นั้นไม่ได้
บอกแค่ Pattern เท่านั้น มันบอกถึงวิธีการนาไปใช้ในชีวิตประจาวันของนักพัฒนาเลยเชียว แต่ขอให้พยายามเข้าใจมันให้ได้ก็แล้วกัน (ผม
จะคอยเอาใจช่วย) เอาละเรามาดูเรื่องโมดูลของ CAB กันดีกว่า
รูปที่ 14: การทางานระหว่างโมดูลต่าง ๆ ของ Composite UI Application Block
จากรูปข้างบนจะเห็นว่าในระบบมี Shell ที่ผมได้เกริ่นไปแล้ว และมีโมดูลอยู่สองโมดูลคือ Moduel1 และ Module 2 ซึ่งสองโมดูลนี้อยู่ใน
กรอบเส้นประด้วยกันทั้งคู่ ซึ่งแสดงให้เห็นว่ามันมีความเป็นอิสระซึ่งกันและกัน (Module Dependency) ผมได้เคยบอกแล้วว่าโมดูลติดต่อ
กับ Shell ผ่านทางคลาส ModuleController ซึ่งจะส่งส่วนแสดงผลที่ต้องการไปแสดงอยู่ใน Shell ที่เป็น Container ชนิดหนึ่งโดยผ่าน

22. 22
กลไกของ CAB (เป็นคาสั่งพิเศษที่เขียนเข้าไปใน ModuleController เพื่อไปเรียกใช้งานฟังก์ชันพิเศษที่อยู่ใน .DLL ที่มาพร้อมกับ CAB
(เวลาใช้งานต้อง Add Reference พวกนี้เข้าไปถึงจะทางานได้)
และโมดูลต่าง ๆ จะติดต่อถึงกันได้โดยผ่านทางกลไกสองแบบคือ Share State Property และ Event Broker Pattern เห็นไหมครับเจอคา
ใหม่เกิดขึ้นอีกแล้ว Share State ยังพอไหวเดาว่ามันเก็บข้อมูลเอาไว้ใน Cache เพื่อใช้งานร่วมกัน แต่ Event Broker นั่นคืออะไร ซึ่งมีทั้ง
Event (เหตุการณ์ที่เกิดขึ้นเมื่อเกิดการกระทากับแอพพลิเคชันเช่น SearchClick() ก็คือคลิกปุ่มเพื่อค้นหาข้อมูลเป็นต้น) และ
EventTopicName ก็คือชนิดของอีเว้นต์ที่กาหนดไว้ในโปรแกรม (มันถูกสร้างเป็น Global Class ที่สามารถมองเห็นร่วมกันได้ทั้งโซลูชัน)
และผมจะบอกเพิ่มเติมว่าการติดต่อสื่อสารกันระหว่างโมดูลไม่ใช่การติดต่อแบบมั่วๆ นะครับ อยู่ดีนักพัฒนาจะไปเขียนโปรแกรมให้โมดูล
นี้ติดต่อกับโมดูลนั้นตามใจตนเองไม่ได้นะ ถ้าทาอย่างนี้บรรลัยวายวอดครับ การติดต่อสื่อสารกันระหว่างโมดูลจะต้องเป็นส่วนหนึ่งของ
การออกแบบในด้านสถาปัตยกรรมซอฟต์แวร์ อยู่ดีๆ มันจะมาเกิดเองตอนเขียนโปรแกรมไม่ได้ (อย่างนี้จะเรียกว่าออกแบบไปเขียน
โปรแกรมต่อไปเรื่อยๆ ) ตอนนี้พวกเราจะทาให้ตัวเราเองเป็นวิศวกรรมซอฟต์แวร์ ด้านไหนก็ว่ากันไป ใครจะเป็นวศวกรรมซอฟต์แวร์ด้าน
วิศวกรรมการแสดงผล วิศวกรรมโครงสร้าง วิศวกรรมการเชื่อมต่อฐานข้อมูล และอื่น ๆ พวกนี้จะเน้นการออกแบบ พัฒนาต้นแบบให้ดีขึ้น
เป็นลาดับ และจัดทารูปแบบที่ดีให้นักพัฒนาไว้ใช้งาน (สาหรับนักพัฒนาที่ทาตามรูปแบบนี้เรามักให้จูเนียร์ Skill Worker (เน้นการทางาน
ตามคาสั่งหรือขั้นตอนการทางานเท่านั้น) หรือ Third Party ที่จะเข้ามาเอาชิ้นส่วนซอฟต์แวร์ของเราไปใช้ สาหรับรายละเอียดของคลาส
EventTopicNames นั้นสามารถดูได้ ในรูปด้านล่าง
รูปที่ 15: โครงสร้าง Infrastructure ของระบบงาน
จากรูปด้านบนจะเห็นไหมครับว่าคลาสที่ชื่อว่า EventTopicNames.cs นั้นจะอยู่ในโปรเจ็กต์ Infrastructure.Interface ภายใต้ส่วน
Infrastructure อีกทีหนึ่ง สาหรับรายละเอียดคลาสเป็นดังนี้ครับ

23. 23
รูปที่ 16: รายละเอียดคลาส EventTopicNames
จากรูปด้านบนจะเห็นว่า EventTopicNames มันก็คือ Global Variable นั่นเอง เพียงแต่มันถูกจัดเก็บให้เป็นที่เป็นทาง อยู่ดีๆ นักพัฒนา
จะมาสร้าง Global Variable เองไม่ได้มันจะถูกสร้างจาก Architect และประกาศให้นักพัฒนาทุกท่านทราบ ท่านผู้อ่านเห็นไหมว่า การนา
Guidance and Best Practices มาใช้นั้นมันบังคับเราให้มีระเบียบไปโดยอัตโนมัติ ทาให้พวกเราสามารถเป็นนักวิศวกรรมซอฟต์แวร์ที่ดีได้
ไม่ยาก โอ… แค่พูดเรื่อง EventTopic เรื่องเดียวก็มาไกลแล้วครับ รายละเอียดเรื่องนี้เอาไว้มาคุยกันต่อก็แล้วกัน
ตอนนี้ก็มาถึงโมดูลแต่ละโมดูลจะติดต่อถึงกันโดยใช้ Event Broker Pattern โดยใช้ Event ที่เกิดขึ้นกับ EventTopicNames ที่เราได้สร้าง
ไว้เป็นพาหะนาไปครับ และการเชื่อมต่อระหว่างกันจะเกิดขึ้นตอนประมวลผลระบบงานครับ หรือตอน Run Time นั่นเอง ดังนั้นจะเห็นว่า
โมดูลไม่ได้ผูกติดกันตลอดเวลาเหมือนฝาแผดอินทร์-จันทร์ สาหรับการติดต่อสื่อสารแบบ Share State นั้นมักจะใช้ภายในโมดูลเดียวกัน
เพื่อความรวดเร็วนะครับ สาหรับรูปด้านล่างก็จะเป็นโมเดลของ Event Broker และ View Navigation Pattern

24. 24
รูปที่ 17: รูปแสดง EventBroker และ View Navigation Pattern
จากรูปด้านบนจะเห็นว่ามีการติดต่อกันระหว่างสองโมดูล ในขณะใดขณะหนึ่ง ฝ่ายหนึ่งจะเป็นผู้ส่ง (Publish) และฝ่ายหนึ่งจะเป็นผู้รับ
(Subscribe) ซึ่งฟังก์ชันต่าง ๆ ที่ต้องการเปิดให้ชาวบ้านเรียกใช้งานก็จะต้อง Subscribe ก่อนนะครับ ถ้าคุณหลบๆ ซ่อนๆ อยู่ใครจะไปรู้ว่า
มี (จริงไหมครับ) เมื่อ Subscribe แล้วก็หมายถึงคุณได้ลงทะเบียนบอกว่า ถ้ามีใครอยากจะใช้บริการค้นหาข้อมูลที่ผมมีอยู่ ซึ่งจะใช้
Global Variable ที่อยู่ในคลาส EventTopicNames เป็นตัวกลางนะครับ ก็บอกได้เลยครับแล้วผมจะส่งข้อมูลไปให้ ส่วนอีกฝ่ายที่ต้องการ
ใช้บริการเช่น ต้องการค้นหาข้อมูลที่มี EventTopicNames ที่เป็นชื่อเดียวกัน ก็จะประกาศออกไป ซึ่งผู้ที่คอบตรวจจับก็จะทาหน้าที่ไปหา
ในข้อมูลที่ได้ลงทะเบียนเอาไว้แล้ว และดูว่ามี EventTopicName ที่ตรงกันหรือไม่ ถ้ามีตรงกันมันก็จะทาหน้าที่เป็นพ่อสื่อให้หนุมสาวได้
พบกัน (โอไปกันใหญ่ เหมือนลงหนวดเลยใช่ไหม)
ถึงตอนนี้ท่านผู้อ่านก็คงจะได้รู้บ้างแล้วว่า CAB 1.0 นั้นมันออกมาเพื่ออะไร หลังจากที่ทาง Microsoft Community ได้ออก CAB มาแล้ว
ก็จะเห็นว่า เรามีรูปแบบและขั้นตอนการพัฒนาหน้าจอเป็นมาตรฐานเพื่อให้นักพัฒนาได้นาไปใช้เป็นแนวทางเดียวกัน แต่ว่าขั้นตอน
ดังกล่าวถึงแม้จะมีขั้นตอนแน่นอนชัดเจนก็ตาม แต่ทาไมเราต้องเขียนขั้นตอนซ้าๆ ทาให้เสียเวลา บางครั้งอาจทาผิดไปขั้นตอนหนึ่ง
โปรแกรมกีมีปัญหาแล้ว ดังนั้นต่อมาก็มีเครื่องมือที่ชื่อว่า Guidance Automation Extension และ Guidance Automation Toolkit ซึ่ง
เครื่องมือทั้งสองนั้นจะติดตั้งลงบน Visual Studio 2005 หรือ 2008 (แล้วแต่เวอร์ชัน) เพื่อทาให้ Architect สามารถนาเอาขั้นตอนต่าง ๆ ที่
กาหนดไว้ใน Guidance หรือคู่มือปฏิบัติงานของนักพัฒนา มาสร้างเป็น Template เก็บไว้ และนามาสร้างโซลูชัน สร้างคลาสตามที่
กาหนด และอื่น ๆ ที่ Visual Studio ทาได้ และสั่งให้มัน Generate ตามขั้นตอนทั้งหมดโดยอัตโนมัต ซึ่งจะทาให้เราสามารถสร้าง
Software Factory Solution ได้เพียงแค่อึดใจเดียว
รูปที่ 18: รูปแสดงวงจรการทางานของ Guidance Automation Toolkit

25. 25
จากรูปแสดงให้เห็นว่าผู้ที่ใช้เครื่องมือ Guidance Automation Toolkit ก็คือ Architect ทาหน้าที่สร้างแม่พิมพ์ชิ้นส่วนซอฟต์แวร์ (ซึ่งใน
เอกสารคู่มือเขาจะใช้คาว่า recipe ซึ่งก็คือสูตรการปรุงอาหาร) ซึ่งเขาคงจะมองว่าการทาซอฟต์แวร์เหมือนการทาอาหาร ซึ่งต้องใช้
ส่วนประกอบการทาอาหารหลายๆ ส่วนนามาผสมรวมกันทีเดียว แล้วก็ได้อาหารออกมาสาเร็จ แต่ผมว่าเจ้า Guidance Automation
Toolkit นี่น่าจะเหมือนกับมะหมีสาเร็จรูปมากกว่า ใส่น้าร้อนกินได้ทันที (รอให้เย็นก่อนนะครับ) หรือคนที่คิดเครื่องมือนี้ชอบการทาอาหาร
เป็นชีวิตจิตใจก็ไม่ทราบ แต่ตอนนี้ผมชักหิวข้าวแล้วนะครับ ได้เวลาทานข้าวเช้าพอดี ตอนนี้เวลาเกือบเก้าโมงเช้า เดี๋ยวมาเขียนต่อครับ
…..
ก็มาต่อกันได้แล้วครับ Guidance Automation Toolkit นั้นเป็นเครื่องมือของ Architect เพื่อทา Recipe ในรูปแบบต่าง ๆ เพื่อให้นักพัฒนา
ใช้งาน สาหรับรายละเอียดของ Recipe แบบต่าง ๆ จะอธิบายเพิ่มเติมในเรื่อง Smart Client Software Factory พอถึงจุดนี้ผู้อ่านได้
สังเกตเห็นไหมว่า รูปแบบและแนวคิดที่ทาง Microsoft Patterns & Practices Community ได้นาเสนอมานี้คืออะไร เมื่อถึงตรงนี้ได้มี
คาศัพท์เกิดขึ้นมาก่อนที่จะไปเป็น Smart Client Software Factory คานั้นก็คือ Software Baseline Architecture สังเกตไหมว่าสิ่งที่เราได้
เรียนรู้มาทั้งหมดนี้มันเริ่มเป็นสถาปัตยกรรมซอฟต์แวร์เบื้องต้นแล้วครับ สาหรับ Baseline ก็หมายถึงมันเริ่มเป็นรูปเป็นร่างที่จะเก็บเป็น
เวอร์ชันแรก ได้แล้ว จากนั้นเราก็จะเพิ่มรายละเอียดเข้าไปเพื่อให้มันเฟรมเวิร์คที่สมบูรณ์แบบมากยิ่งขึ้น
จากนั้น Patterns & Practices Community ก็ได้ฤกษ์ออก Smart Client Software Factory เมื่อเดือน มิ.ย. 2549 ใช้กับ Visual Studio
2005 เห็นไหมว่า Smart Client Software Factory (SCSF) มีอายุครบสามขวบกว่า ๆ แล้วครับ เวอร์ชันปัจจุบันคือเวอร์ชันของ Apr 2008
สาหรับ Visual Studio 2008 ถ้าใครสนใจเข้าไปดาวน์โหลดใช้งานได้ที่ http://smartclient.codeplex.com/ แต่ว่าก่อนที่จะติดตั้ง SCSF
คุณต้องติดตั้งซอฟต์แวร์ดังต่อไปนี้
- Visual Studio 2008 SP1
- Guidance Automation Extension (GAX) และ
- Guidance Automation Tool Kit (GAT) ตามลาดับนะครับ ถ้าไม่ตามลาดับก็ติดตั้งไม่ได้แต่ถ้าถอดมันออกก็ต้องถอน GAT
ออกก่อน แล้วจึงจะถอน GAX นะครับ
- จากนั้นติดตั้ง SCSF เวอร์ชัน Apr 2008 ซึ่งมันจะติดตั้งไลบรารีของ Enterprise Library และ CAB 1.0 มาให้โดยอัตโนมัติ
เป็นยังไงบ้างครับ คุณพร้อมที่จะใช้งาน Smart Client Software Factory แล้วหรือยังครับ ตอนนี้ผมจะสอนให้ท่านลองใช้งานเบื้องต้น
(สาหรับ GAX และ GAT นั้นให้ดูว่ามันเป็นเวอร์ชันสาหรับ VS 2008 หรือไม่ด้วยนะครับ) เริ่มลองใช้งานทาดังนี้ครับ
1. เปิด Visual Studio 2008
2. คลิก File/ New/ Project ก็จะปรากฏวินโดวส์ของ New Project ดังในรูปต่อไป