Chapter 1 3 หลักการและ Diagram ที่ใช้ใน Object-Oriented Design

1. Chapter 13 หลักการและ Diagram ที่ใช้ใน Object-Oriented Design

2. จุดประสงค์ 1. เพื่อให้นักศึกษาเข้าใจกระบวนการ Refinement 2. เพื่อให้นักศึกษาได้เข้าใจบทบาทและความสำคัญของ Refinement ที่มีต่อ Object-Oriented Design

3. 13.1Refinement หัวใจสำคัญของ OOD Refinement คือกระบวนการ เพิ่มเติมหรือทำให้ Diagram ที่ทำไว้แล้วในขั้นตอน Analysis มีความเหมาะสม และง่ายต่อการนำมาพัฒนาเป็นระบบงานในเครื่องคอมพิวเตอร์ได้ในที่สุด การทำ Refinement นั้นทำได้กับทุกๆ Diagrams ที่สร้างขึ้นจากขั้นตอน Analysis ไม่ว่าจะเป็น Use Case Diagram, Class Diagram, Sequence Diagram และ State Diagram สิ่งสำคัญที่ต้องจำไว้เป็นหลักการในการทำRefinement คือ การทำ Refinement ที่ Use Case Diagram จะมีผลต่อการทำ Refinement ของ Class Diagram ในขณะที่การทำ Refinement ของ Class Diagram จะมีผลต่อการทำ Refinement ของ Sequence Diagram และ State Diagram และการทำ Refinement ระหว่าง Sequence และ State Diagram ก็จะมีผลกระทบต่อกันและกันเสมอ

4. ข้อเตือนใจที่ต้องคำนึงไว้เสมอในการทำ Refinement 2 ข้อ 1. ต้องทำเรียงลำดับจากUse Case,Class, Sequence และ State Diagram ตามลำดับ ไม่ควรข้ามขั้นตอน แต่การย้อนกลับมาทำ Refinement ใน Diagram ที่เคยทำไปแล้วก็ไม่ถือว่าเป็นการผิดหลักการแต่อย่างใด และการย้อนกลับก็ควรจะย้อนอย่างเป็นวงจร (Use Case -> Class -> Sequence -> State -> Use Case -> Class …) 2. เมื่อทำRefinement แล้วต้องทำให้ Diagrams ต่างๆ ที่เคยทำไว้ มีคอมพิวเตอร์มาเกี่ยวข้อง หรือเอื้ออำนวยต่อการทำงานด้วยคอมพิวเตอร์ เช่น การเพิ่ม Class ของ User Interface เข้าไปยัง Class Diagram (ซึ่งตามปกติไม่จำเป็นต้องมี หากไม่ได้ทำงานด้วยคอมพิวเตอร์) และการเพิ่ม Function สำหรับการป้อนค่าและแสดงค่า Attributes ต่างๆ ของ Class เข้าไปไว้ในทุกๆ Class Diagram (การป้อนค่าและการแสดงค่า ทำเพื่ออำนวยความสะดวกในการทำ Input และ Output ของคอมพิวเตอร์) เป็นต้น

5. 13.2Use Case Diagram Refinement ซึ่งมีหลักการดังนี้ 1. พิจารณาว่าแต่ละUse Case นั้นสามารถแยกแยะออกมาเป็น Use Case ย่อยๆ ได้หรือไม่ ถ้าสามารถทำได้ให้แยกแยะ Use Case นั้นๆ ออกมา 2. สร้างความสัมพันธ์ระหว่างUse Case เดิมและ Use Case ที่แยกย่อยออกมา จากที่ทำไว้ในความสัมพันธ์ระหว่าง Use Case คือ <<Uses>> หรือ <<Extends>> ให้ครบถ้วน และต้องคอยตรวจสอบไม่ให้มี Use Case ใด Use Case หนึ่งที่ไม่มีความสัมพันธ์กับ Use Case อื่น หรือไม่มีความสัมพันธ์กับ Actor ใดเลย (Use Case ที่อยู่โดดๆ) ในขณะเดียวกัน หากสามารถแยกแยะ Actor หนึ่งตัวให้เป็นประเภทต่างๆ ที่ละเอียดขึ้น หรือการจัดประเภทของ Actor ให้มีลักษณะเป็นจำพวกเดียวกันโดยอาศัยหลักการ Generalization ได้ ก็ให้ทำในขั้นตอนนี้

6. 3. สร้างUse Case List เพื่อแสดงรายการ Use Case ที่มีทั้งหมด ทั้งก่อนและหลังจากการทำ Refinement 4. ในUse CaseList ก่อนการทำ Refinement ให้ List ว่ามี Class ใดบ้างอยู่ภายใน Use Case แต่ละตัวโดย Class หนึ่งๆ อาจจะอยู่ใน Use Case มากกว่า 1 Use Case ก็ได้ แต่หลักการสำคัญก็คือทุกๆ Class ต้องอยู่ภายใน Use Case ใด Use Case หนึ่งเป็นอย่างน้อย จะต้องไม่มี Class ใดที่ไม่อยู่ใน Use Case ใดเลย แต่อย่างไรก็ตามอาจจะยกเว้น Class ของ Actor เท่านั้นที่ไม่ต้องอยู่ที่ใน Use Case ใดเลยก็ได้ในกรณีที่ Problem Domain ไม่ได้เน้นให้ Actor มีตัวตนในคอมพิวเตอร์

7. 13.3Class Diagram Refinement มีหลักการดังนี้ 1. ในแต่ละClass ให้พิจารณาว่ามี Attributes ตัวใดบ้างที่ต้องมีการรับค่าจากภายนอก และ/หรือ มีการส่งค่าของ Attribute นั้นออกสู่ภายนอก ถ้ามีให้เพิ่ม Function พร้อมทั้ง Parameters ที่จำเป็นทั้งหมดเพื่อการรับเข้า และ/หรือ ส่งออกค่าของ Attribute เหล่านั้น เข้าไปที่ Class ด้วย โดยกำหนดให้ Function ต่างๆ ที่เพิ่มเข้ามามี Visibility เป็น Public (มองเห็นได้จากภายนอก) ทั้งหมด เพราะ Function เหล่านี้ต้องถูกเรียกใช้โดย Object อื่นเสมอ 2. จากหลักการข้อ 1 ข้อพึงระวังในการเพิ่มFunction เพื่อการนำเข้า/ส่งออก ค่าของ Attributes นั้นคือ เรื่องของ Subclass และ SuperClass การเพิ่มเติมใดๆ ลงไปยัง SuperClass จะหมายถึงการเพิ่มเติมลงใน Subclass แต่การเพิ่มเติมใน Subclass จะไม่มีผลกระทบให้ Superclass เปลี่ยนแปลง

8. 3. ทุกๆAttributes และ Functions ในแต่ละ Class ต้องมี Visibility (Private, Protected หรือ Public) ที่แน่นอน จะต้องไม่มี Attributes และ Functions ใดที่ไม่มี Privacy ในกรณีที่ยังไม่แน่ใจว่า Privacy ของ Attributes หรือ Functions นั้นเป็นอะไร ให้ยึดหลักการต่อไปนี้ หากเป็น Attributes ให้ตั้ง Privacy เป็น Private ไว้ก่อน แต่หากเป็น Function ให้ตั้ง Visibility เป็น Public ไว้ก่อน ถ้ามี Attributes ใดที่มี Visibility เป็น Private ซึ่งจำเป็นต้องมีการส่งค่าของ Attributes เข้า/ออก ให้ทำตามข้อ 1 4. ทุกๆAggregation และ Association จะต้องมี Cardinality กำกับเสมอ และต้องกำกับทิศทางของ Association ให้ชัดเจน อาจจะระบุ Role ของ Class ที่มี Association ต่อกันด้วยก็ได้ ตัวอย่างเช่น ใน Association ครู-นักเรียน Role ของครูคือผู้สอน ในขณะที่นักเรียนมี Role เป็นผู้เรียน เป็นต้น

9. 5. พิจารณาProblem domain โดยละเอียดว่า หากใช้คอมพิวเตอร์เข้ามาร่วมทำงาน จำเป็นต้องมี Class ใดเพิ่มเข้ามาบ้าง ตัวอย่างที่ดีของ Class เหล่านี้คือ Class ของ User Interface (GUI) 6. หลังจากเสร็จสิ้นการทำRefinement แล้ว ให้พิจารณาว่า Class ที่เพิ่มขึ้นนั้นอยู่ใน Use Case ใดให้ระบุ Class ต่างๆ ทั้งที่มีอยู่เดิมและที่เพิ่มเข้ามาว่าอยู่ใน Use Case ใดบ้างลงใน Use Case List หลังจากการทำ Refinement เพื่อเป็นการตรวจสอบว่า ก่อนและหลังทำ Refinement แล้ว Class ต่างๆ อยู่ใน Use Case ที่ถูกต้องหรือไม่ และทุกๆ Class จะต้องมีอยู่ใน Use Case ใด Use Case หนึ่งเสมอ

10. 13.4Sequence Diagram Refinement มีหลักการดังนี้ 1. จากClass Diagram ที่ได้ทำ Refinement แล้ว ให้พิจารณาว่ามี Function ใดใน Class ใดบ้างที่ยังไม่ปรากฏใน Sequence Diagram ให้พิจารณาหาตำแหน่งของ Function นั้นๆ ใน Sequence Diagram หากหาไม่ได้ ให้ทำเครื่องหมายใดๆ ไว้เพื่อทำการลบทิ้งภายหลัง 2. นำClass ที่เป็นส่วนของ User Interface (ที่เพิ่มเข้ามาใน Class Diagram) มาเพิ่มเติมลงในทุกๆ Sequence Diagram ที่มี Actor มาเกี่ยวข้อง แล้วสร้างลูกศรแสดงกิจกรรมเพื่อสร้าง Sequence Diagram ที่สมบูรณ์โดยพยายามนำ Function ที่มรอยู่แล้วใน User Interface หรือ Class อื่นๆ มาสร้างเป็นลูกศร แต่หากหาไม่ได้ ให้เพิ่ม Function ใหม่ๆ เข้าไป ในขณะเดียวกันต้องเข้าไปเพิ่มใน Class Diagram ด้วย

11. 3. ในกิจกรรมที่เกิดขึ้นจากClass ใด Class หนึ่งนั้น พยายามระบุว่า Class นั้นๆ จะมีอายุอยู่ในช่วงเวลาใดบ้าง ซึ่งสัญลักษณ์การแสดงช่วงชีวิตนั้นทำได้โดยการเพิ่มเติมภาพสี่เหลี่ยมผืนผ้าที่มีความกว้างพอประมาณแต่ความยาวเท่ากับระยะห่างระหว่างเส้นกิจกรรมเส้นแรกที่เข้าหรือออกจาก Class ถึงเส้นสุดท้ายที่มีเส้นกิจกรรมเข้าหรือออกจาก Class ซึ่งสัญลักษณ์นี้จะวางอยู่บนเส้นแสดงการเดินไปของเวลา (เส้นประ) ใน Sequence Diagram สัญลักษณ์สี่เหลี่ยมที่ใช้แสดงช่วงชีวิตนี้จะมีส่วนช่วยให้ผู้ที่จะพัฒนาระบบ (ซึ่งอาจไม่ใช่ผู้ออกแบบ) ทราบได้ว่าควรที่จะสร้าง Object จาก Class หรือทำลาย Objects ณ ช่วงเวลาใดบ้างเพื่อให้ Objects ที่สร้างมาดำเนินกิจกรรมต่างๆ ของระบบต่อไปได้

12. 4. หากมีการคำนวณหรือส่งค่าParameter หรือค่าของ Attributes ให้เพิ่มภาพการส่งข้อมูลหรือการคำนวณข้อมูลลงใน Sequence Diagram ด้วย 13.5State Diagram Refinement มีหลักการดังนี้ 1. ตรวจสอบState Diagram เดิมว่ามีความละเอียดพอหรือไม่ ถ้าไม่ให้เพิ่มเติมรายละเอียดลงใน State Diagram เดิมให้สมบูรณ์ที่สุดเท่าที่จะทำได้ เพราะ State Diagram ยิ่งมีความละเอียดเท่าใด การสร้าง Program ก็จะยิ่งสะดวกยิ่งขึ้นเท่านั้น 2. เพิ่มเติม State Diagram ของ Function ที่เกิดใหม่และของ function ของ Class ที่เกิดขึ้นใหม่

13. 13.6 ตัวอย่างการทำRefinement ตัวอย่างการทำ Refinement ของ Use Case Diagram ของระบบพัฒนาข้อมูลขององค์กรภาครัฐ Diagram จาก OOA 1 นำข้อมูลเข้า 3 นำเสนอข้อมูล 2 วิเคราะห์ข้อมูล นักวิเคราะห์ระบบ นักศึกษา 4 บริโภคข้อมูล บุคคลภายนอก รูปUse Case Diagram ของระบบพัฒนาข้อมูลขององค์กรภาครัฐ

14. จากUse Case Diagram ของระบบพัฒนาข้อมูลขององค์กรภาครัฐ ประกอบไปด้วย Use Case ทั้งหมด 4 Use Case คือ (1)การนำข้อมูลเข้า (2)การวิเคราะห์ข้อมูล (3)การนำเสนอข้อมูล และ (4)การบริโภคข้อมูล โดยมี 3 Actor คือ ผู้ป้อนข้อมูล บุคคลภายนอก และนักวิเคราะห์ข้อมูล ด้วยหลักการการทำRefinement กับ Use Case Diagram สามารถปรับ Use Case Diagram ได้โดยการให้รายละเอียดกับบาง Use Case เพิ่มมากขึ้น เช่น (1) เพิ่มUse Case “ตรวจสอบสิทธิในการบริโภคข้อมูล” เพื่อใช้ในการ extends กับ Use Case บริโภคข้อมูล (2) เพิ่มUse Case “การพิจารณา Parameter ต่างๆ” เพื่อให้ Use Case “วิเคราะห์ข้อมูล” ได้เรียกใช้ (uses) ซึ่งการปรับเปลี่ยนในลักษณะนี้ระบุไว้ใน กฎข้อ 2 ในหัวข้อ 13.2

15. นอกจากนี้ยังพบว่า ทั้งActor ผู้ป้อนข้อมูลและ Actor ผู้วิเคราะห์ข้อมูลต่างก็เป็นผู้ที่อยู่ในองค์กรภาครัฐเหมือนกัน เราสามารถสรุปได้ว่า Actor ทั้งสองประเภทนี้เป็นเจ้าพนักงาน ดังนั้นจึงสามารถใช้ Generalization เพื่ออธิบายความสัมพันธ์นี้ การปรับเปลี่ยนในลักษณะนี้ยึดตามกฎข้อ 2 ในหัวข้อ 13.2

16. Diagram ที่ได้จากการทำ Refinement (ระบบพัฒนาข้อมูลขององค์กรภาครัฐ) เจ้าพนักงาน นักวิเคราะห์ข้อมูล ผู้ป้อนข้อมูล นำข้อมูลเข้า นำเสนอข้อมูล บริโภคข้อมูล วิเคราะห์ข้อมูล <<uses>> <<extends>> บุคคลภายนอก พิจารณา Parameter ต่างๆ ตรวจสอบสิทธิในการบริโภคข้อมูล รูปUse Case Diagram ที่ผ่านการทำ Refinement แล้ว

17. ตัวอย่าง การทำRefinement ของ Class Diagram ของระบบบุคลากรในห้างสรรพสินค้า Diagram จาก OOA ห้างสรรพสินค้า -ชื่อ -ประเภท -สถานะ +เปิดร้าน() +ปิดร้าน() หัวหน้าแผนก แผนก เจ้าหน้าที่ -ชื่อ -ชื่อ -ประเภท -ตำแหน่ง -สถานะ -เงินเดือน +จัดทำงบกำไรขาดทุน() +เปิดแผนก() +ปฎิบัติงาน() +ปิดแผนก() +ลางาน() รูป Class Diagram ของระบบบุคลากรในห้างสรรพสินค้า

18. Diagram ที่ได้จากการทำ Refinement กับ Class Diagram (ระบุคลากรในห้างสรรพสินค้า) ห้างสรรพสินค้า แผนก เจ้าหน้าที่ -ชื่อ -ชื่อ -ชื่อ -ประเภท -ประเภท -ประเภท -สถานะ -สถานะ(เปิดหรือปิด) -สถานะ +เปิดร้าน() +เปิดแผนก() +เปิดร้าน() 1..n 1..1 1..n ทำงานใน +ปิดร้าน() +ปิดแผนก() +ปิดร้าน() +ตั้งชื่อ(ชื่อ) +ตั้งชื่อ(ชื่อ) +ตั้งชื่อ(ชื่อ) +บอกชื่อ() +บอกชื่อ() +บอกชื่อ() +เปลี่ยนประเภท(ประเภท) +เปลี่ยนประเภท(ประเภท) +เปลี่ยนประเภท(ประเภท) +บอกประเภท() +บอกประเภท() +บอกประเภท() +บอกสถานะ() +บอกสถานะ() +บอกสถานะ() งบกำไรขาดทุน หัวหน้าแผนก -ปีของงบ 1..n จัดทำ 1..1 -ยอดคงค้าง หมายเหตุ คำที่เขียนด้วยอักษรตัวเอียงและเข้ม คือส่วนที่เพิ่มเข้าไป +จัดทำงบ(ปี,ยอดคงค้าง) +จัดทำงบกำไรขาดทุน() +แก้ไขงบ(ปี,ยอดคงค้าง) +ดูราลละเอียดของงบ(ปี) รูป Class Diagram ที่ผ่านการทำ Refinement แล้ว

19. ตัวอย่าง การทำ Refinement ของ Sequence Diagram ของระบบขายน้ำอัดลมอัตโนมัติ Diagram จาก OOA :ตู้ขายน้ำอัดลมอัตโนมัติ :เครื่องรับเงิน :เครื่องเก็บน้ำผลไม้ :ช่องปล่อยน้ำผลไม้ หยอดเหรียญและเลือกประเภทน้ำอัดลม() รับเงิน() Customer ปล่อยน้ำอัดลม() ลดจำนวนน้ำในตู้() [ให้เงินมาเกิน] ทอนเงิน() รูป SequenceDiagram ของระบบขายน้ำอัดลมอัตโนมัติ

20. Diagram ที่ได้จากการทำ Refinement กับ Sequence Diagram (ระบบขายน้ำอัดลมอัตโนมัติ) :ตู้ขายน้ำอัดลมอัตโนมัติ :แผงหน้าปัด :เครื่องรับเงิน :เครื่องเก็บน้ำผลไม้ :ช่องปล่อยน้ำผลไม้ หยอดเหรียญ() T=เลือกประเภทน้ำอัดลม() ขายน้ำ(T) Customer P=คิดเงิน(T) เก็บเงิน(PP) ปล่อยน้ำอัดลม(1) ลดจำนวนน้ำอัดลม(1) [มีจำนวนเงินที่ให้มาเกิน] ทอนเงิน(PP-P) หมายเหตุ รูปสี่เหลี่ยมใสที่วางไว้บนเส้นแสดงเวลา (เส้นประ) หมายถึงช่วงเวลาที่ Object ของ Class นั้นๆ ยัง Active อยู่ รูป Sequence Diagram ที่ผ่านการทำ Refinement แล้ว

21. ตัวอย่าง การทำ Refinement ของ State Diagram ของการทำงานของลิฟต์ Diagram จาก OOA /Turn Off Want Up/ Go Up /Turn On Idle Move Up Floor > 1 / Go Down Floor = 1 Want Down/ Go Down Desired Floor reached Floor <> 1 & Desired Floor Reached Move Down Reach รูป State Diagram

22. Diagram ที่ได้จากการทำ Refinement กับ State Diagram /Turn Off Idle Move Up Want Up/ Go Up /Turn On do/floor = floor + 1 entry/floor=1 (floor=Max)/Stop Floor > 1 / Go Down Floor = 1 Want Down/ Go Down Desired Floor reached Move Down Reach Floor <> 1 & Desired Floor Reached do/floor = floor - 1 entry/Stop (floor=1)/Stop รูป State Diagram ที่ผ่านการทำ Refinement แล้ว