Summary 1
จาก Applying UML and Patterns 3rd edition, Craig Larman หน้า 1-60
Chapter 1: OOA/D
1.2 Learning goal
หลักสำคัญของการศึกษา OOA/D คือการสามารถกำหนดหน้าที่ให้กับ software objects ได้อย่างชำนาญ
1.3 Analysis & Design
- Analysis คือการสำรวจปัญหา เช่น ถ้าจะสร้างระบบเล่นหุ้น จะใช้ในวัตถุประสงค์ใด มีความสามารถอย่างไรบ้าง
- Design คือการสร้างแนวคำตอบที่ตรงต่อ requirement บางครั้งการ Design จะข้ามรายละเอียดระดับล่างๆ ไป
1.4 OOA/D
- Object Oriented Analysis (OOA) เน้นการหาและอธิบาย objects หรือแนวคิดในปัญหา เช่น ถ้าสร้างระบบข้อมูลการบินก็อาจจะมี เครื่องบิน เที่ยวบิน นักบิน เป็นต้น
- Object Oriented Design (OOD/OD) เน้นการกำหนด software objects และความสัมพันธ์ระหว่าง objects ที่ตรงต่อ requirement เช่น เครื่องบินอาจจะมี attribute tailNumber และเมธอด getFlightHistory ซึ่งตรงนี้ก็จะกลายเป็นคลาส Plane ใน Java ตอนเขียนโค้ด
OOA/D สนใจเฉพาะในส่วน logic ของโปรแกรม เพราะส่วนอื่นๆ อาจจะเกี่ยวข้องกับเทคโนโลยีที่ใช้มากเกินไป เช่นถ้าใช้ Swing ก็ออกแบบแบบหนึ่ง ถ้าใช้ PHP ก็แบบหนึ่ง
1.5 ตัวอย่าง
(แนะนำให้ดูภาพประกอบในหนังสือ)
1. กำหนด use case
วิธีหนึ่งในการวิเคราะห์ requirement คืออาจจะเขียนเป็นเรื่อง หรือสถานการณ์ที่คนเข้ามาใช้โปรแกรมของเรา เรียกว่า use case เช่น
- เล่นเกมทอยลูกเต๋า: ผู้เล่นต้องการทอยลูกเต๋า โปรแกรมแสดงผลลัพท์ออกมา ถ้าค่าของลูกเต๋าเท่ากับ 7 ผู้เล่นชนะ ถ้าไม่ใช่ผู้เล่นจะแพ้
2. กำหนด domain model
Domain model เป็นแผนภาพแสดง object หรือ concept สำคัญ
(ดูภาพประกอบในหนังสือ หรือใน lecture 1)
ในเกมทอยลูกเต๋าก็จะมี Player, Dice, DiceGame ใน domain model เป็นต้น
ข้อสังเกตคือ domain model ไม่ใช่การอธิบาย software objects แต่เป็นการแสดงภาพคอนเซปต์ของปัญหา
3. กำหนดหน้าที่ของวัตถุ และวาดผังการโต้ตอบ
Sequence diagram เป็นแผนภาพแบบ dynamic แสดงลำดับของการส่งข้อความระหว่างวัตถุใน software (ซึ่งก็จะช่วยให้เห็นว่าเมธอดเรียกกันเป็นลำดับอย่างไร)
4. วาด class diagram
class diagram เป็นการแผนภาพแบบ static โดยแสดง attribute, method ของคลาสโดยไม่ระบุการทำงานของมัน
แผนภาพ class diagram จะต่างกับ domain model ตรงที่จะเป็นการ map ตรงตัวกับ class ในโปรแกรม
1.6. UML?
UML มีการใช้ 3 ลักษณะ
- ใช้วาดคร่าวๆ เพื่อช่วยวิเคราะห์ส่วนที่ซับซ้อนของโปรแกรม
- ใช้เป็นพิมพ์เขียวของโปรแกรม มี 2 ลักษณะคือ
- เอาโปรแกรมที่มีอยู่แล้วมาเขียน UML (อาจจะใช้โปรแกรมช่วย) ทำให้คนอ่านเข้าใจถึงโครงสร้าง และการปฏิสัมพันธ์ระหว่าง object ในโปรแกรม
- วาดก่อนเขียนโปรแกรม วาดแล้วอาจจะใช้เครื่องมือที่แปลง UML เป็นโค้ดก็ได้ถ้าวาดไว้ละเอียดพอ แต่ก็ต้องโค้ดมือเพิ่มเข้าไปด้วย
- ใช้เขียนโปรแกรม คือวาดการทำงานทั้งหมดเป็น UML และใช้เครื่องมือมาช่วยแปลงเป็นโค้ด อันนี้ยังอยู่ในขั้นทฤษฎีอยู่
มุมมองการใช้ UML มี 3 แบบ
- เชิงคอนเซปต์ ใช้อธิบายวัตถุในโลกจริง
- เชิง spec ใช้อธิบายโครงสร้างของโปรแกรมแต่ไม่ได้จำเพาะเจาะจงภาษาโปรแกรมใดๆ
- เชิง implementation ใช้อธิบายโครงสร้างโปรแกรมในภาษาหนึ่ง
ส่วนมากแล้วจะไม่ค่อยออกแบบในแนวข้อ 2 (เช่น ละรายละเอียดว่าเป็น Java หรือ .NET) แต่จะมองในลักษณะข้อ 3 มากกว่า
Chapter 2: Iterative, Evolutionary Development and Agile
keyword สำคัญในบทนี้คือ iterative development หรือการแบ่งงานเป็น iteration (แบบที่เรียนใน Indv. Process) ซึ่งจะมีทวนในหัวข้อ 2.2
2.1 UP
Unified Process (UP) เป็นลักษณะการพัฒนาแบบ iterative แบบหนึ่ง โดยแบบที่นิยมใช้เรียกว่า Rational Unified Process (RUP)
UP ค่อนข้างยืดหยุ่นได้ สามารถเอาวิธีทำงานจากกระบวนวิธีอื่นๆ มาใช้ได้ เช่น การทำ test-driven development (เรียนไปนิดหน่อยใน Indv. Process เป็นกระบวนการพัฒนาแบบเขียน test นำโค้ด) ซึ่งมาจากกระบวนวิธี Extreme Programming (XP)
2.2 Iterative
หัวข้อนี้สรุปเนื้อหาจาก Indv. Process ถ้าแม่นแล้วก็ข้ามไป
Iterative development แบ่งงานเป็น iterations (project เล็กๆ) ที่มีเวลาจำกัด (ประมาณ 2-6 สัปดาห์) โดยมีลักษณะ "timeboxed" คือถ้าตั้งเวลาเท่าไรก็ต้องเท่านั้นห้ามเกิน ถ้าทำไม่เสร็จก็ต้องลดสโคปงานลงแล้วไปใส่ใน iteration ถัดไป
การทำงานแบบ iteration ใช้หลักการว่าอย่ารีบไปโค้ด (don't rush to code) คือก่อนจะเริ่ม iteration ก็ต้องมีการวางแผนก่อนเริ่มงานนิดหน่อย
ข้อดีของการแบ่งงานแบบนี้คือ
- ทำงานสำเร็จมากขึ้น โปรแกรมมีปัญหาน้อยลง
- จัดการความเสี่ยงได้แต่เนิ่นๆ
- มองเห็นความคืบหน้าได้รวดเร็ว
- ลดความซับซ้อน จากเดิมที่ต้องเสียเวลาวิเคราะห์ระบบนานๆ ก็แตกเป็นระบบย่อยๆ ทำให้ทำงานง่ายขึ้น
- สิ่งที่พบระหว่าง iteration ก็จะเป็นบทเรียนให้ iteration ต่อๆ ไป
- ได้รับ feedback และการทดลองใช้ได้เร็ว ทำให้ได้ระบบที่ตรงกับความต้องการของผู้ใช้มากขึ้น
ข้อดีอย่างนึงของการที่มี feedback ที่เร็วทำให้กระบวนการ iterative รองรับการเปลี่ยนแปลงได้มาก แทนที่จะเดาว่า user อยากได้อะไร ก็ให้ user ทดลองใช้ระบบพื้นฐานดู user อาจจะตอบว่า "แบบนี้แหละตามที่สั่งเป๊ะเลย แต่พอมาใช้แล้วอยากได้อีกแบบมากกว่า" ซึ่งการที่เรารู้ตรงนี้เร็วๆ มันทำให้เราแก้งานได้แต่เนิ่นๆ แล้วก็ทำให้โปรแกรมนั้นตรงกับสิ่งที่ผู้ใช้หวังมากกว่า
2.3 Waterfall
Waterfall เป็นกระบวนการที่นิยมใช้กันแต่ก่อน โดยใช้วิธีว่ากำหนด requirement ทั้งหมดมาก่อน แล้วก็ออกแบบทั้งหมดให้เรียบร้อยก่อนแล้วถึงเริ่มทำงาน
Waterfall ไม่ใช่วิธีที่ดีเพราะมันเอามาจากอุตสาหกรรมอื่นๆ ซึ่ง requirement อาจจะไม่ได้เปลี่ยนไปเปลี่ยนมาเหมือน software ฉะนั้นแล้วการมี feedback แต่เนิ่นๆ จะดีกว่า
บางทีเราอาจจะเผลอใช้ Waterfall ใน Iterative ก็ได้ ถ้ารู้ตัวว่ามานั่งลิสต์ "ทุกอย่าง" ก่อนทำงาน เช่นมานั่งเขียน use case ทั้งหมด เขียน UML ทั้งหมด อันนี้เป็นสัญญาณแล้วว่าเริ่มเข้าวิถีของ Waterfall
2.4 ออกแบบอย่างไรในโลก Iterative
ทีนี้จะมีคำถามว่าแล้วถ้าบอกว่าห้ามออกแบบทุกอย่างทีเดียวแล้วจะทำงานกันอย่างไร ก็ลองดูจากตัวอย่างนี้
- เริ่มแรกก็จัด requirement workshop อาจจะสักสองวัน (เป็นแบบ timeboxed ห้ามยืดเพิ่ม) โดยให้มีทั้งฝ่ายขายและโปรแกรมเมอร์
- วิเคราะห์ requirement แบบ high level เช่น หาชื่อ use case, feature ต่างๆ, requirement หลักๆ ตรงนี้ไม่ต้องเอาแบบให้สมบูรณ์ 100% ก็ได้
- ให้ฝ่ายขายเลือกจากข้อ 1 มาสัก 10% ที่มีลักษณะดังนี้
- สำคัญต่อระบบ (จะสร้างฟีเจอร์นี้ได้ต้องสร้างแก่นของโปรแกรมขึ้นมาก่อน)
- สำคัญต่อธุรกิจ (ฟีเจอร์ที่เอาไปโม้ให้ลูกค้าได้)
- ความเสี่ยงสูง (เช่น ต้องสามารถรองรับงานได้ 500 งานพร้อมๆ กัน)
- วิเคราะห์ความต้องการโดยละเอียดของสิ่งที่เลือกไว้ในข้อ 2
- ก่อนเริ่ม iteration ให้แบ่งบางส่วนของงานที่เลือกไว้ในข้อ 1.2 มาออกแบบและสร้างใน iteration ถัดไป (เพราะบางทีงานอาจจะใหญ่เกินกว่าที่จะทำใน iteration เดียวได้) แล้วก็ทำ task breakdown แบ่งเป็นงานย่อยๆ
- ทำ iteration อาจจะสัก 3-4 สัปดาห์
- ช่วงแรกให้ออกแบบระบบ อาจจะวาดภาพ UML ขึ้นมาคร่าวๆ
- โค้ด โดยอาศัยโครงที่วางแผนไว้ในข้อ 1 เข้ามาช่วย
- ทดสอบโปรแกรมด้วยวิธีต่างๆ
- ก่อนจะหมด iteration มานึกดูว่างานที่เหลือเสร็จมั้ย ถ้าไม่เสร็จก็ต้องลด scope งานลงและยกยอดไป iteration ถัดไป
- วันก่อนหมด iteration ให้หยุดโค้ดไปทำอย่างอื่น
- วันที่หมด iteration ให้ demo งานให้กับลูกค้าและขอ feedback
- จัด requirement workshop ครั้งที่ 2
- ทบทวนผลลัพท์จากครั้งก่อน
- เลือก 10% มาวิเคราะห์อีก (ฉะนั้นตอนนี้งาน 20% จะถูกวิเคราะห์แล้วถ้ารวมกับ workshop ครั้งก่อน)
- ทำ 1-4 ซ้ำหลายๆ ครั้ง
- พอทำ requirement workshop ไปหลายๆ ครั้งจนวิเคราะห์งานไปได้เกือบหมดแล้วจะเข้าสู่ช่วง elaboration ซึ่งจะมีการประมาณงานที่เหลือและเวลาที่จะใช้ในการสร้างชิ้นงานสุดท้ายขึ้นมา โดยอาศัยข้อมูลจากการปฏิบัติงานที่ผ่านมา
- หลังจากนี้แล้วอาจจะไม่มีการจัด requirement workshop เพราะ requirement ค่อนข้างจะนิ่งแล้ว
2.6 Agile method
วิธีการพัฒนาแบบ Agile มักมีลักษณะเป็น timeboxed iterative, วางแผนแบบยืดหยุ่นได้ โดยเน้นให้เกิดความ "agility" (คล่องตัว) - เร็ว ยืดหยุ่นได้ ตอบสนองต่อการเปลี่ยนแปลง
ตัวอย่างวิธี agile เช่น Scrum, XP, UP
2.7 Agile modelling
- Agile ไม่ได้แปลว่าไม่ต้องออกแบบ
- การออกแบบทำเพื่อให้เข้าใจตรงกัน ไม่ใช่ใช้ทำเป็นเอกสารกำกับ
- การวาด UML ทำให้เราสามารถหาวิธีออกแบบที่เหมาะสมได้ง่ายกว่าการไปนั่งโค้ด
- อย่านั่งวาด UML ทั้งหมด ตรงไหนที่ง่ายๆ ก็ข้ามไปงมในโค้ดเอาได้ แต่ตรงที่มันยากๆ ก็ควรออกแบบเป็น UML มาก่อน
- ใช้เครื่องมือง่ายๆ ไม่ต้องเอาคอมมาวาด ใช้ไวท์บอร์ดดีกว่าเพราะมันสามารถวาดได้ไวกว่า และแก้ได้ง่ายกว่า แถมใหญ่กว่าจอคอม
- อย่าวาดคนเดียว เพราะเราวาดเพื่อให้คนอื่นเข้าใจตรงกันกับเรา
- วาดหลายๆ ภาพพร้อมกัน เช่นวาด class diagram พร้อมๆ กับ interaction diagram
- ไม่ต้องเน้นว่าวาด UML ตรงตามตำราเป๊ะ แค่เอาว่าวาดแล้วเข้าใจตรงกันเป็นพอ
- อย่าวาดเพื่อส่งให้คนอื่นโค้ด แบบนั้นเป็นวิธี waterfall
2.10 Phase ของ UP
การใช้ UP แบ่งงานเป็น 4 เฟส
- Inception - ประมาณแผนการ ประเมินงาน สโคปงานคร่าวๆ
- Elaboration - ปรับปรุงแผนงานและพัฒนาแกนของระบบ แก้ปัญหาที่ความเสี่ยงสูง ระบุ requirement และสโคปงานหลักๆ ให้ชัดเจน
- Construction - พัฒนางานความเสี่ยงต่ำที่เหลือ เตรียมส่งงาน
- Transition - ทดสอบระบบ ส่งงาน
เฟสตรงนี้ไม่เหมือนกับใน Waterfall ที่จะมีขั้นตอน requirement, design, ... แต่ใน UP เนี่ยการกำหนด requirement หรือการ design มีได้ในแทบทุกเฟส ไม่ใช่ว่าต้องทำทีเดียวให้เสร็จทั้งหมด
2.11 UP Discipline
Artifact คือสิ่งที่เกิดขึ้นจากกระบวนการ UP ไม่วาจะเป็นโค้ด เอกสาร แผนภาพ หรืออื่นๆ
Artifact ถูกจัดเป็นกลุ่มๆ ตามกระบวนการที่ทำให้เกิดชิ้นงานนั้นๆ เรียกว่า Discipline ตัวที่เราสนใจก็มี
- Business Modeling - ผลิต แผนภาพ Domain Model
- Requirement - ผลิต use case และ supplementary specification artifact
- Design - ผลิตแผนภาพ Design Model
ใจความสำคัญอย่างนึงของ UP คือทุกอย่างเป็น optional จะไม่ทำเอกสารอะไรก็ได้ ไม่ทำงานอะไรก็ได้ โดยมีเอกสารที่สรุปว่าทำงานอะไรบ้างเรียกว่า Development Case
Chapter 4: Inception
Inception คือช่วงที่ตกลงทำความเข้าใจโครงการ และศึกษาความเป็นไปได้ของโครงการ
ในช่วง Inception อาจจะมีเอกสาร (artifact) ต่างๆ ออกมา ตามรายการในตารางหน้า 50 แต่เอกสารเหล่านี้ไม่ได้แปลว่ามันจะสมบูรณ์ครบถ้วนเสมอไป
Chapter 5: Evolutionary Requirement
- นิยามของ Requirement: Project ต้องเป็นไปตาม Requirement
- Requirement แบ่งเป็น FURPS+
- Functional - ฟีเจอร์, security
- Usability - เอกสารประกอบการใช้
- Reliability - เสถียรภาพของระบบ
- Performance - ความเร็วและการใช้ทรัพยากรของระบบ
- Supportability - ดูแลรักษาง่ายแค่ไหน แปลภาษาได้ง่ายไหม ปรับแต่งได้มากน้อยแค่ไหน
-
- คือ อื่นๆ เช่น
- Implementation - ข้อจำกัดด้านทรัพยากร ภาษา เครื่องมือ ฮาร์ดแวร์
- Interface - ข้อจำกัดในการติดต่อกับระบบภายนอก
- Operation - การจัดการระบบในการทำโปรแกรมไปใช้
- Packaging - เช่น ต้องส่งงานเป็นกล่อง
- Legal - เรื่องลิขสิทธิ์ต่างๆ
- ใช้ FURPS+ เพื่อตรวจเช็คว่าได้คิดถึง requirement ในทุกหมวดไม่ตกหล่น
- requirement สามารถเก็บในเอกสารต่อไปนี้ (มี ไม่มีก็ได้)
- use case model - สถานการณ์การใช้โปรแกรมทั่วไป ส่วนมากจะกล่าวถึง requirement ด้านพฤติกรรมของโปรแกรม
- supplementary specification - อะไรที่เขียนเป็น use case ไม่ได้ เช่นเรื่องความเร็วของโปรแกรม เรื่องลิขสิทธิ์ของโปรแกรม หรืออะไรที่ไม่ใช่ use case เช่น สามารถออกรายงานได้
- glossary - กำหนดคำศัพท์หลักๆ และ requirement เกี่ยวกับข้อมูล เช่น จะตรวจสอบข้อมูลที่รับว่าถูกต้องอย่างไร รายงานมีหน้าตาอย่างไร
- vision - เอกสารสั้นๆ เพื่อให้เข้าใจภาพโดยรวมของโครงการ สรุป requirement ชั้นสูงซึ่งจะไปลงรายละเอียดใน use case อีกที
- business rules/domain rules - ข้อกำหนดที่ใช้กับหลายๆ โครงการได้ เช่นกฎหมายด้านภาษีที่โปรแกรมหลายๆ ประเภทที่มีการคิดเงินต้องใช้ ตรงนี้อาจจะเขียนไว้ใน supplementary specification ก็ได้ แต่ถ้ามีโครงการพัฒนาหลายอันก็อาจจะแยกออกมาเพื่อใช้ร่วมกันได้
- เอกสารทั้งหมดจะเก็บยังไงก็ได้ อาจจะทำเป็นวิกิ เป็นเว็บเพจ เป็นโปสเตอร์ ได้ทั้งนั้น