วันจันทร์ที่ 22 ตุลาคม พ.ศ. 2555

Chapter 7 System models


บทที่ 7  แบบจำลองระบบ

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

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

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

7.2 แบบจำลองตามแนวเชิงโครงสร้าง 
        แบบจำลองที่จะต้องสร้างแบ่งออกเป็น 2 ชนิดได้แก่ 
        1. แบบจำลองกระบวนการ (Process Model) ใช้จำลองขั้นตอนการทำงานของระบบ แผนภาพที่ใช้คือ แผนภาพกระแสข้อมูล (Data Flow Diagram : DFD) หมายถึงแผนภาพที่แสดงให้เห็นถึงทิศทางการไหลของข้อมูลที่มีอยู่ในระบบ จากกระบวนการทำงานหนึ่งไปกระบวนการทำงานหนึ่ง หรือไปยังส่วนอื่นที่เกี่ยวข้อง ไม่ว่าจะเป็นแหล่งจัดเก็บข้อมูล (Data Store) หรือผู้เกี่ยวข้องที่อยู่นอกระบบ (External Agent) DFD แบ่งแกเป็น 2 ประเภท ได้แก่ 
                1.1 แผนภาพการไหลในระดับตรรกะ (Logical DFD) ที่แสดงกระบวนการของระบบในระดับแนวคิด (Conceptual) เท่านั้น กล่าวคือ แสดงให้เห็นถึงการไหลของข้อมูลพอสังเขปไม่ลงลึกถึงรายละเอียด และไม่ได้ใช้คำศัพท์ทางเทคนิคมากนัก และมักใช้ขั้นตอนการวิเคราะห์ความต้องการ 
                1.2 แผนภาพกระแสข้อมูลในระดับกายภาพ (Physical DFD) เป็น DFD ที่แสดงให้เห็นรายละเอียด ภายในกระบวนการเช่น ชื่อกระบวนการ วิธีการทำงาน แหล่งกำเนิดและปลายทาง เป็นต้น โดยมีการใช้ศัพท์เทคนิคเพื่อให้สื่อสารกับโปรแกรมเมอร์ได้ง่ายขึ้น แผนภาพชนิดนี้ใช้ในขั้นตอนการออกแบบระบบ 

        แสดงตัวอย่างของกระบวนการ Compute and Printing Invoice หรือกระบวนการคำนวณและสั่งพิมพ์ใบกำกับสินค้า ข้อมูลเข้าสู่ Process 4.1 Compute คือหมายเลขใบส่งสินค้า (Deliver Note) และขอมูลใบสั่งขาย (Sale Order Data) เมื่อ Process 4.1 คำนวณเงินจำนวนทั้งหมดแล้ว จะส่งข้อมูลสำหรับสั่งพิมพ์ใบกำกับสินค้า (Invoice Data) ไปยัง Process 4.2 Printing Invoice เพื่อสั่งพิมพ์ใบกำกับสินค้า และส่งไปพร้อมกับสินค้าเพื่อให้ลูกค้า 

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

        จะเห็นว่าในระบบงานขายนั้นต้องปฏิสัมพันธ์กับบุคคลอื่นที่อยู่นอกระบบทั้งหมด 4 กลุ่ม ได้แก่ ระบบประมวลผลใบสั่งซื้อ (Order Processing) ฝ่ายบริหารงานขาย (Sale Management) ฝ่ายผลิตและคลังสินค้า (Manufacturing and Store) และลูกค้า (Customer) เมื่อเห็นภาพรวมของระบบงานขายแล้ว  ทีมงานจะต้องสร้าง DFD ระดับถัดมาคือระดับ 0 เพื่อแสดงให้เห็นกระบวนการทำงานภายในของระบบ และนำแต่ละกระบวนการมาแตกเป็นกระบวนการย่อยในระดับ 1,2 ต่อไปเรื่อยๆ จนกว่าจะไม่สามารถแบ่งย่อยกระบวนการได้อีก อย่างไรก็ตาม กระบวนการที่จะสามารถแบ่งย่อยต่อไปได้อีก จะต้องมีกระบวนการย่อยอยู่ภายในอย่างน้อย 2กระบวนการ แสดงตัวอย่าง DFD Level 0,1 ดังรูป

        2. แบบจำลองข้อมูล (Data Model) ใช้จำลองโครงสร้างข้อมูลทั้งหมดในระบบ แผนภาพที่ใช้คือ แผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล (Entity Relationship Diagram: ERD) หมายถึงแผนภาพที่ใช้เป็นเครื่องมือสำหรับจำลองข้อมูลซึ่งจะประกอบไปด้วย Entity (แทนกลุ่มของข้อมูลที่เป็นเรื่องเดียวกัน/เกี่ยวข้องกัน) และความสัมพันธ์ระหว่างข้อมูล (Relationship) ที่เกิดขึ้นทั้งหมดในระบบ นอกจากนี้ทุกๆ Entity จะมี Attribute เป็นตัวบ่งบอกถึงลักษณะหรือคุณสมบัติของ Entity นั้นด้วย 

        จากรูป เป็นการแสดงความสัมพันธ์ระหว่าง Entity โดย Entity Sale Order จะดึงข้อมูลใบสั่งซื้อมาจาก Entity Order และดึงข้อมูลลูกค้ามาจาก Entity Customer จะเป็นว่า ERP แสดงให้เห็น Attribute ของ Entity ที่สำคัญของระบบซึ่งมีลักษณะคล้ายกับ Attribute ของข้อมูลในฐานข้อมูล จึงมีประโยชน์อย่างมากในการออกแบบฐานข้อมูล 

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

        แบบจำลองของระบบที่สร้างขึ้นตามแนวทางเชิงวัตถุนั้น มีหลากหลายชนิดตามระเบียบวิธีปฏิบัติ ทีบุคคลหรือองค์กรต่างๆ กำหนดขึ้น ทำให้ผู้เชี่ยวชาญด้านการวิเคราะห์และออกแบบเชิงวัตถุได้รวมตัวกันกำหนดภาษารูปภาพเพื่อใช้สร้างแบบจำลองเชิงวัตถุขึ้น เรียกว่า UML (Unified Modeling Language) โดยแบ่งออกเป็น 2 กลุ่ม รวมทั้งหมด 9 แผนภาพ ดังนี้ 
        1. Structural Diagram เป็นกลุ่มแผนภาพที่แสดงให้เห็นโครงสร้างเชิงสถิติ ของระบบคือ โครงสร้างในส่วนที่ไม่มีการเปลี่ยนแปลงหรือเคลื่อนไหวแม้จะมีเหตุการณ์ใดๆ เกิดขึ้น แบ่งออกเป็นแผนภาพชนิดต่างๆ ดังนี้
Class Diagram เป็นแผนภาพที่ใช้ในการแสดงกลุ่มของคลาส โครงสร้างของคลาส และ Interface ตลอดจนแสดงความสัมพันธ์ (Relationship) ระหว่างคลาส การเริ่มต้นสร้าง Class Diagram นั้นส่วยใหญ่จะต้องค้นหาอ็อบเจ็กต์ใน Use Case ก่อน เทคนิคที่ใช้ในการค้นหาจะแตกต่างกันออกไปตามประสบการณ์ของทีมงาน เช่น ค้นหาจากคำอธิบายรายละเอียด ของ Use Case โดยชื่อคลาสหาได้จาก คำนาม ส่วน Attribute ของคลาสหาได้จากคำคุณศัพท์ และ Method ของคลาสหาได้จาก คำกริยา หรือบางครั้งอาจเริ่มต้นด้วยการหาชื่อคลาส แล้วตั้งคำถามหรือหาความรับผิดชอบของคลาสเพิ่มเติม เพื่อค้นหา Attribute และ Method ของคลาส 

        จากตัวอย่างจะเห็นว่า Class Diagram นอกจากจะแสดงให้เห็นถึงคลาสทั้งหมดแล้ว ยังแสดงให้เห็นความสัมพันธ์ระหว่าคลาสด้วย ไม่ว่าจะเป็นความสัมพันธ์แบบ Specialization (เส้นตรงมีหัวลูกศร) Association (เส้นตรง) และอื่นๆ รวมถึงแสดงสมาชิกของอ็อบเจ็กต์ (1..1,0..*)

                Object Diagram  เป็นภาพที่ใช้ในการแสดงกลุ่มของอ็อบเจ็กต์และความสัมพันธ์ระหว่างอ็อบเจ็กซ์ที่เกิดขึ้นในคลาสต่างๆ ของ Class Diagram 

Component Diagram เป็นภาพที่ใช้แสดงถึงโครงสร้างทางกายภาพของโปรแกรม ประกอบด้วยส่วนประกอบต่างๆ ที่เรียกว่า Component ซึ่งหมายถึงส่วนประกอบย่อยของซอฟต์แวร์ของระบบงานทั้งหมด ดังนั้น Component Diagram จะเป็นแผนภาพที่แสดงความสัมพันธ์ระหว่าง Component ของซอฟต์แวร์ที่ใช้ในระบบ ทำให้เห็นว่าประกอบไปด้วยไฟล์ใดบ้าง ส่วนใหญ่จะแสดงไฟล์ที่เป็น Source code, Binary code และไฟล์ที่ใช้ Run ได้แก่ .exe, .dll 
  
                Deployment Diagram  เป็นแผนภาพที่แสดงโครงสร้างทางด้านฮาร์ดแวร์ของระบบงาน ส่วนใหญ่จะใช้ร่วมกับ Component Diagram โดยการมองอุปกรณ์ฮาร์ดแวร์ทั้งหมดเป็นอ็อบเจ็กต์หรือคลาสได้เช่นเดียวกัน

        2. Behavioral Diagram เป็นกลุ่มแผนภาพที่แสดงให้เห็นภาพเชิงกิจกรรมของระบบ (Dynamic) คือแสดงให้เห็นพฤติกรรมของระบบที่มีการเปลี่ยนแปลงไปเมื่อมีเหตุการณ์ใดๆ เกิดขึ้น และแสดงให้เห็นถึงความสามารถของระบบที่ดำเนินการในบางหน้าที่บางอย่างได้ แบ่งออกเป็นแผนภาพชนิดต่างๆ ดังนี้
                Use Case Diagram  เป็นเครื่องมือในการจำลองหน้าที่ของระบบที่ผู้ใช้ต้องการ เนื่องจาก Use Case Diagram เป็นแผนภาพที่ใช้แสดงถึงขั้นตอนการทำงานที่สำคัญของระบบ (Use Case) อาจกล่าวได้ว่าเป็นหน้าที่หรืองานที่ระบบจะต้องปฏิบัติ เพื่อตอบเสนองต่อผู้กระทำต่อระบบ (Actor) โดย Use Case Diagram จะแสดงความสัมพันธ์ระหว่าง Use Case และ Actor ด้วย 


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

                Collaboration Diagram  เป็นแผนภาพที่แสดงให้เห็นถึงการปฏิสัมพันธ์ (Interaction) ระหว่างอ็อบเจ็กต์เช่นเดียวกับ Sequence Diagram แตกต่างกันตรงที่ในส่วนของ Collaboration Diagram ไม่มีสัญลักษณ์แสดงลำดับในการส่ง Message อย่างชัดเจน แต่จะเน้นส่วนของการแสดงถึงความสัมพันธ์ระหว่างอ็อบเจ็กต์ตามลักษณะการทำงาน 

                Statechare Diagram เป็นแผนภาพที่แสดงให้เห็นพฤติกรรมของอ็อบเจ็กต์เช่นเดียวกับแผนภาพในกลุ่ม Behavioral Diagram อื่นๆ แต่ Statechart Diagram จะเน้นที่การแสดงให้เห็นถึงสถานะ (Transition) ที่มีต่อเหตุการณ์ (Event) ที่เกิดขึ้นในช่วงชีวิตของอ็อบเจ็กต์ 1 ช่วง 

                Activity Diagram เป็นแผนภาพที่แสดงให้เห็นถึงลำดับการดำเนินกิจกรรม (Activity) จากกิจกรรมหนึ่งไปยังอีกกิจกรรมหนึ่ง ซึ่งเกิดจากการทำงานของอ็อบเจ็กซ์ภายในระบบ ลักษณะของแผนภาพจะคล้ายกับ Flow Chart 

ไม่มีความคิดเห็น:

แสดงความคิดเห็น