วัตถ ุประสงค์
1. เข้ าใจขั้นตอนการวิเคราะห์ และออกแบบระบบงาน
ด้ วยวิธีเชิงวัตถุ
2. บอกหลักการเขียนผังงานเชิงวัตถุได้
การวิเคราะห์และออกแบบระบบงานด้วยวิธีการเชิงวัตถ ุ
1. วิธีการวิเคราะห์ และออกแบบระบบ
งานต่ างๆ
2. ขั้นตอนการวิเคราะห์ ระบบงานด้ วย
วิธี CRC
3. ขั้นตอนการออกแบบระบบงานด้ วย
วิธี CRC
วิธีการวิเคราะห์และออกแบบระบบงาน
การวิเคราะห์ และออกแบบระบบงานด้ วยวิธีการเชิ งวัต ถุ
เป็ นการพัฒนาระบบงานให้ มีคุณลักษณะเชิ งวัตถุ ได้ มีผ้ ูพัฒนา
แนวทางหลายแนวทางได้ แก่
1. วิธี GOOD คิดค้ นพัฒนาโดยองค์ การ NASA ใช้
หลักการของการค้ นหาวัตถุจากผังงาน DFD แบบ Top-down และ
มีความเกีย่ วข้ องโดยตรงกับภาษา Ada
2. วิธีการ HOOD คิดค้ นพัฒนาโดยองค์ การ ESPIRIT
ของสมาคมยุโรป ใช้ หลักการค้ นหาวัตถุจากผังงาน DFD แบบ
วิธีการวิเคราะห์และออกแบบระบบงาน
Top-down ใช้ งานบนภาษา Ada คล้ ายกับ GOOD แต่ มีข้อจากัด
ในด้ าน Inheritance, Polymorphism และ Genericity ไม่ ได้ รับ
การยอมรับเท่ าที่ควร
3. วิธีการ OOSD พัฒนาโดย Wasser man เหมาะกับ
ระบบ Real-Time
และไม่ ติดยึดกับภาษาใด ๆ สนับสนุ น
Inheritance, Abstraction
4. วิธีการ OODLE พัฒนาโดย Shlaer, Mellor ลักษณะ
การพัฒนาแบบวนซ้า และมีผงั งานที่ใช้ งานในด้ าน Class,
วิธีการวิเคราะห์และออกแบบระบบงาน
Class-structure, Dependency และ Inheritance
5. วิธีการ OOD/Booch พัฒนาโดย Grady Booch ลักษณะ
การพัฒนาแบบวนซ้า (Recursive) และเพิม่ พูน (Incremental) มี
การแสดงความเกี่ยวข้ องระหว่ าง class ขั้นตอนของการพัฒนา
ประกอบด้ วย การระบุ classes และ object ในขั้นตอนเชิงตรรก
(Abstraction) การระบุคุณลักษณะ (Semantics) ของ class และ
object การกาหนดความเกี่ยวข้ อง-สั มพันธ์ ระหว่ าง class และ
object การพัฒนา (Implement) หลังการกาหนด class และ object
วิธีการวิเคราะห์และออกแบบระบบงาน
ให้ เป็ นรู ปธรรม
6. วิธีการ OMT พัฒนาโดย James Rumbough ผังงาน
ต่ างๆ ครอบคลุมทั้งสภาวะสถิตย์ (Static) และสภาวะพลวัต
(Dynamic) เช่ น Object model, Dynamic model และ Functional
model เป็ นวิธีที่นิยมใช้ งานมากวิธีหนึ่ง
7. วิธี RDD (Responsibility-Driven-Design) พัฒนาโดย
Wirfs-Brock, et.al. อาจเรียกอีกวิธีว่า CRC (Class Responsibility
Collaboration) สนับสนุนหลักการพืน้ ฐานของ OO ในด้ าน Class,
วิธีการวิเคราะห์และออกแบบระบบงาน
Object, Inheritance นอกจากนั้นยังสนับสนุนการเรียกใช้ Classes
อืน่ ๆ ที่เกีย่ วข้ องกัน (Collaboration) ลักษณะการพัฒนาเป็ นแบบ
Exploratory และ Analysis ขั้นตอนของ RDD (Exploratory)
ประกอบด้ วยการระบุ object การสร้ างความสั มพันธ์ ของ Object
(= class) การระบุ Responsibilities ของแต่ ละ object และการระบุ
ความเกีย่ วข้ องกับ Class อืน่ ๆ ส่ วน RDD (Analysis) ประกอบด้ วย
การระบุแผนภูมิ Hierachy ของ Class การระบุ Subsystem และ
การระบุคุณลักษณะของ Class, Subsystem วิธีการ RDD เป็ นวิธีที่
วิธีการวิเคราะห์และออกแบบระบบงาน
ใกล้ เคียงกับการปฏิบัติงานด้ วยมือ (Manual) และหากผนวก
วิธีการกาหนดรู ปแบบโครงสร้ างข้ อมูล (Conceptual Data Model
- ER diagram) * กับการจัดทารู ปแบบงานต้ นแบบ (Story Board)
จะทาให้ การวิเคราะห์ และออกแบบระบบงานเที่ยงตรงยิ่งขึ้ น ใน
เอกสารบรรยายนี้จะใช้ กรณีศึกษาซึ่ งนาเสนอด้ วยวิธีการ RDD
หรือ CRC Method
______________________________________________________________________________________________
* AJH Simon “Object Oriented Analysis and Design Development of Computer Science, University of She…..
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
การวิเคราะห์ ด้วยระบบงานด้ วยวิธี CRC มีลักษณะการ
ทางานที่เป็ นขั้นเป็ นตอน และมีการใช้ งานเอกสารกากับการทางาน
ในทุกขั้นตอน ทาให้ ช่วยในการทบทวนความต้ องการระบบงาน
(Requirements) ได้ อย่ างดี
ขั้นตอนของการวิเคราะห์ ระบบงานมีดงั นี้
1. จัดทาผังปริบท (Context diagram) ของระบบงาน ผัง
Context diagram จะแสดงภาพโดยรวมของระบบงานว่ ามี
ผู้เกีย่ วข้ อง (Stabehoders) ใดบ้ างที่มีการกระทาต่ อระบบ ที่
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ทั้ ง ผู้ ใ ห้ ข้ อ มู ล หรื อ ใช้ ข้ อ มู ล ต่ อ ระบบงาน ผู้ เ กี่ ย วข้ อ งอาจเป็ น
บุคคล หรือระบบงานภายนอก (External System) ความเกีย่ วข้ อง
ที่ผู้เกีย่ วข้ องมีต่อระบบ เป็ นความต้ องการหลัก ๆ ของระบบงานที่
ผังมีการร้ องขอ / การกระทาต่ าง ๆ ต่ อระบบจะเรียก Use case
ตัวอย่ างเช่ น
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
Customer
Shipment
Supplier
Invoice
Order
Order
System
Credit status
Customer DB
Inquiry
Customer
Response
Invoice
Accounting
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
2. การกาหนดผู้เกี่ยวข้ อง (Actor)
หลังจากการพัฒนา
Context diagram แล้ ว ขั้นตอนต่ อมาคือการระบุ Actor ซึ่ง Actor
อาจจะเป็ นทั้งผู้ให้ ข้อมูล (ก่ อให้ เกิดการกระทา) หรื อผู้ใช้ ข้อมูล
(รอรับการกระทา) เพือ่ แก้ ปัญหาการทาซ้า การกาหนด Actor จึง
พิจารณาจาก Actor โดยดูจากผู้เกีย่ วข้ องที่เป็ นผู้ร้องขอการกระทา
ต่ อระบบงาน (Initiation The Input) เท่ านั้น
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
Actor
Activity Type
initiate/request
Use Case
Actor
customer
Activity
initiate
initiate
initiate
initiate
Use Case
Order
Inquiry
Credit status
Invoice
customer DB
Supplier
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ในกรณีนี้ Actor คือ Customer, Customer DB, Supplier เป็ นต้ น
3. การกาหนดความเชื่อมโยงของ Use Case (Use Case
Dependency) เป็ นขั้นตอนการแสดงภาพความเกี่ยวข้ อง การขึ้ น
ตรงต่ อกันของ Use Case การระบุความเกี่ยวข้ องกันจะต้ อง
พิจารณาจากลักษณะของงาน (Application Domain) ของระบบ
สารสนเทศที่กาลังพิจารณา ในบางครั้ งอาจมีการแสดงเงื่อ นไข
“ และ ” “ หรือ ” บ่ อยครั้งพบว่ า Use Case บางตัวถูกเรียกใช้ งาน
บ่ อย ๆ โดย Use Case อืน่ ๆ Use Case นีจ้ ะถูกระบุเป็ น Use Case
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ประเภท Abstract Use Case (Include) ใน Use Case หนึ่ง ๆ อาจมี
ความสลับซับซ้ อน มีการคานวณหรือมีข้นั ตอนมากมาย Use Case
นีอ้ าจจะถูกทาให้ สลับซับซ้ อนน้ อยลง โดยการดึง/แยก เอางานบาง
อย่ างออกมารวมไว้ ที่อกี Use Case หนึ่ง ๆ (หรืออาจแตกออกได้ อกี
หลาย Use Case) Use Case ประเภทนีเ้ รียก Extension Use Case
ตัวอย่ างของลักษณะการเรียกใช้ งาน Use Case เช่ น
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
Buy Order
Entry
Sell Order
Entry
<<include>>
<<include>>
Trade Order
Entry
<<extend>>
Invalid
Trade Number
Invalid
Choice
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ตัวอย่ าง Use Case Dependency ได้ แก่
Request
Product
Process Order
Customer
Pull Items
Ship Order
Ware
House
Sales
Receive
Order
Bill Customer
Pay Bill
Close Order
Sales
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
การจัดทา Use Case Dependency จะแสดงกลุ่มของ Use Case ที่
เกีย่ วข้ องกันในการทางาน หนึ่ง ๆ ภาพตีกรอบจะช่ วยแสดงระบบ
ย่ อย (Subsystem) ของระบบงานได้
ช่ วยในการระบุ System
Architecture
4. ขั้นตอนการจัดทา Use Case Diagram ผัง Use Case
Diagram จะมีลักษณะเป็ นภาพปริบทของระบบงานคล้ ายภาพใน
ขั้ น ตอนที่ 3 แต่ ตี ก รอบให้ อยู่ ใ นขอบเขต เพื่ อ ให้ สะดวกใน
การศึกษาภาพรวมของระบบงาน
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
Request
Product
Receive
Order
Pull Item
Customer
Pay Bill
Process Order
Ship Order
Bill Customer
Sales
Close Order
Ware house
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
5. ขั้นตอนการจัดทารายละเอียดของแต่ ละ Use Case (Use
Case Description)
ขั้นตอนนีจ้ ะใช้ ในการบรรยายการทางาน
ของแต่ ละ Use Case โดยข้ อมูลจะมาจากการสั มภาษณ์ ผู้ใช้ งาน
(user)
Use Case Description จะคล้ ายคลึงกับการพรรณา
กระบวนการ (Process - Data Dictionary) ใน DFD รายละเอียด
ของ Use Case Description ประกอบด้ วย
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
1. Use Case Name : ชื่อของ Use Case
2. Actor
: ชื่อผู้เกีย่ วข้ องกับ Use Case
3. Description
: บรรยายการทางานของ Use Case
คร่ าวๆ ว่ าทางานเกีย่ วกับอะไร
4. Normal Course : เป็ นกรอบแสดงรายละเอียดของการ
ทางานขั้นตอนย่ อย ๆ (Step) ตั้งแต่ ต้ังต้ นจนกระทั่งสิ้นสุ ด โดยใน
แต่ ละขั้นตอนย่ อยจะประกอบด้ วยประโยคหนึ่งๆ ซึ่ งมี ประธาน
กริยาและกรรม เพียงชุดเดียว ในแต่ ละบรรทัดจึงมีลกั ษณะ
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
เป็ นงานชั้นปฐมภูมิ (Primitive)
5. Precondition
: ใช้ ระบุ Use Case หรือเหตุการณ์
อืน่ ๆ ใดทีจ่ ะกระทา / เกิดขึน้ ก่ อนจะมากระทา use case นี้
6. Post-condition : ใช้ ระบุ Use Case หรือเหตุการณ์
อืน่ ๆ ใดที่จะกระทา / เกิดขึน้ หลังจากกระทา Use Case นีส้ าเร็จ
7. Assumption
: ใช้ หมายเหตุในเรื่องอืน่ ใดที่สาคัญๆ
ของ Use Case นี้ เช่ น ระบบรักษาความถูกต้ อง ความปลอดภัย
เป็ นต้ น
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ตัวอย่ างของ use case description : Normal course ได้ แก่
Use Case
: Prepare Roster
Actor
:
Pre
:
Discrepancy List for the current week is alredy prepared and printed
Post
:
Roster is prepared
User
Mainflow ;
step1
: For each task
- Task's detail is abtained
- Task information is displayed on screen
- System randomly select flatmate for this task {use case - assigntask}
- The assignment is recorded and displayed
step2
: The full roster is disp;ayed with the weight for each person
step3
: Manager confirms the roster
step4
: Manager ask for hard copy
step5
: System prints the roster
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
เมื่อได้ จัดทา Use Case Description : Normal Course ซึ่ง
พรรณนาขั้นตอนการทางานปกติครบถ้ วนแล้ ว นักวิเคราะห์ ระบบ
จะทาการสอบทานความถูกต้ อง / ครบถ้ วน ในความต้ องการของ
ระบบงาน (Functional Requirement) กับ User จนสมบูรณ์
6. ขั้นตอนการจัดทารายละเอียด Use Case Description
เชิง Alternate
เป็ นขั้นตอนขยายจากขั้นตอนที่ 5 โดย
นักวิเคราะห์ ระบบจะบรรยายงานย่ อยๆ ที่จะต้ องกระทาในกรณีที่
ผิดเงือ่ นไขจากเหตุการณ์ ปกติ เช่ น
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
Normal
Step 1 : if N น้ อยกว่ าหรือเท่ ากับ 100
N เท่ ากับ N+1
end if
Alternate
Step 1 : print “N=”,N
Alternate flow ;
Step 3 : - Manager may manually edit the roster
Step 4 : - Manager may exit without requesting hard copy
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
เช่ น หากเหตุการณ์ ในขั้นตอนที่ 1 ถูกต้ อง เงื่อนไขจะกระทาใน
คาสั่ งที่ระบุใน Step 1 (กรณี Normal) แต่ หากผิด เงื่อนไข
(N>100) จะพิมพ์ค่า N ออกมาเป็ นต้ น
จากภาพ Use Case Description จากขั้นตอน 5 หากมี
ขั้นตอน Alternate สามารถยกตัวอย่ างได้ ดัง Alternate Flow
7. ขั้นตอนการระบุวตั ถุ (Object Identification) เป็ น
ขั้นตอนที่ใช้ ในการหาวัตถุ (Potential Objects) ในระบบงาน
การดาเนินการจะทาโดยการนา Use Case Description
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
(Normal +Alternate) ของทุก ๆ Use Case มาพิจารณา หา
คานาม (อาจเป็ นประธานหรือกรรม) โดยการขีดเส้ นใต้ คานามทุก
ๆ คา ที่ปรากฏใน Normal และ Alternate Step ทุก ๆ Step
หลังจากนั้นจะนาคานามทั้งหมดมาพิจารณาทีละคา ๆ ว่ าสมควร
คัดเลือกเป็ น Object หรือไม่ โดยพิจารณาจากนิยามของ Object
เป็ นหลัก
“ Object จะมีคุณลักษณะ (Attribute) และการกระทา
(Behavior) ในตัวมันเอง ”
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ดังนั้นคานามบางคาอาจเป็ นเพียง attribute (ตัวแปรแสดง
คุณลักษณะของวัตถุ) คานามพ้ องรู ป (Synonyms) หรือคานามที่
ไม่ เกีย่ วกับระบบงานโดยตรง ให้ พจิ ารณาตัดออก
8. ขั้นตอนการสร้ าง Class Diagram หลังจากที่ได้
รวบรวม Object ต่ าง ๆ ไว้ จากทุก ๆ Use Case Description
แล้ ว ขั้นตอนต่ อมาคือขั้นตอนการจัดกลุ่ม จัดหมวดหมู่ของเหล่ า
วั ต ถุ ต่ า งๆ เข้ า ด้ ว ยกั น บางวั ต ถุ เ ป็ นพวกเดี ย วกั น ในลั ก ษณะ
ประเภทหนึ่ง (kind-of) หรือในลักษณะ ส่ วนหนึ่ง (part-of)
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
หรื อ อาจเป็ นเพราะเกี่ ย วข้ อ งกั น เพราะมี ก ารเรี ย กใช้ งานกั น
(Relationship) คาแนะนาในการจัดทา Class Diagram ในที่นีข้ อ
เสนอแนะแนวทางไว้ สองแนวทางดังนี้
8.1 การพิจารณาความสั มพันธ์ แบบ kind-of (“ ”)และ
แบบ part-of (“ ”) ให้ พจิ ารณาจากธรรมชาติของ Objects ต่ าง
ๆ ว่ ามีความเกี่ยวข้ องกันในสองแนวทางหรือไม่ ความเกี่ย วข้ องกัน
อาจเกิดจากการมี Attribute และ / หรื อ มี Behavior ร่ วมกัน
(Common) หลังจากพิจารณาได้ ลกั ษณะร่ วมแล้ ว จะทาการดึงสิ่ งที่
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ร่ วมกันนีอ้ อกมา แล้ วสร้ าง / กาหนด วัตถุใหม่ ขึน้ อีก 1 ตัว ทาการ
ดูแลสิ่ งทีเ่ ป็ นลักษณะร่ วมกันของเหล่ าวัตถุต่างๆ อีกต่ อหนึ่ง วัตถุนี้
จะเรี ยกวัตถุแม่ (Super type) ที่จะดูแลกลุ่มวัตถุต่าง ๆ โดย มี
ลักษณะจะถ่ ายทอดให้ ลูก ๆ (Generalization) เป็ นลักษณะของ
ตนเองแทน ซึ่ ง อาจมี ลั ก ษณะเป็ นรู ป ธรรม (Concrete) หรื อ
นามธรรม (Abstract) ลักษณะที่เป็ นนามธรรม จะเป็ นลักษณะที่
ยอมให้ Object ลูก ๆ ทาการ Override เพือ่ ทางานให้ ต่างกันไปได้
(Polymorphism)
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ส่ วนลักษณะพิเศษทีแ่ ต่ ละวัตถุมีแตกต่ างจากวัตถุอนื่ ๆ จะคงรักษา
ไว้ ในวัตถุพนื้ ฐาน (Specialization) ตัวอย่ างเช่ น
Course Offering
Location
Open()
add student
Student
Professor
Major
Tenure Status
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
วัตถุ Student และ Professor ต่ างเป็ น kind Of Person (user) ใน
มหาวิทยาลัย จึงอาจสร้ างวัตถุ Registration User ปรับปรุ ง Class
Diagram ใหม่ ได้ เป็ น
Course Offering
Student
Professor
Registration User
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
8.2 การพิจารณาความสั มพันธ์ แบบการเรี ยกใช้ งานซึ่ งกัน
และกัน (Relationship) การพิจารณาความสั มพันธ์ นี้เป็ นความ
เกี่ยวข้ องกันระหว่ างวัตถุ เพราะเกี่ยวข้ องกันในการติดต่ อขอใช้
บริ การ method ต่ างๆ โดย object หนึ่ง ต่ อ object อื่นๆ ผ่ าน
message การจัดทา Relationship จะพิจารณาจากความเกีย่ วข้ อง
กันในลักษณะของงาน (Application Domain) อนึ่งนอกเหนือจาก
การพิจารณา Application Domain แล้ ว อาจใช้ วิธีการศึกษา
ความสั มพันธ์ ของกลุ่มข้ อมูล (Attribute) จากผังความเกีย่ วข้ อง
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
(Entity Relationship diagram : ER) ซึ่งผัง ER Diagram จะ
จัดทาจาก การทาปกติ (Normalization) รายงานต่ าง ๆ จากผัง
ปริบท (Context Diagram) ซึ่งในผัง ER Diagram จะแสดงกลุ่ม
ก้ อนของข้ อมูล (Attribute) ดังนั้น ผัง ER Diagram จะเป็ น
ครึ่งหนึ่งของผัง Class Diagram จากผัง ER Diagram จะช่ วยใน
การแสดงภาพความสั มพันธ์ กนั ระหว่ างวัตถุ ตัวอย่ างจากผัง ER
Diagram ของ Application หนึ่งๆ เมื่อเทียบเคียงกับผัง ClassDiagram เชิง OO แล้ ว จะมีความใกล้ เคียงกันดังภาพ
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
จากภาพของ ER diagram ข้ างต้ น จะพิจารณาการ
ปรับเปลีย่ น ผัง ER เป็ นผังงาน OO โดยขั้นตอนดังนี้
1. สร้ างผัง OO จาก Data Entity ในผัง ER
2. บรรจุ Attribute ลงใน Object (จาก Data Entity)
3. พิจารณา/กาหนด การกระทาลงใน Object โดยพิจารณา
จาก Relation ระหว่ าง Data Entity (เช่ น works for, works on)
4. กรณีที่ผงั EER Diagram (มีการสร้ าง Data Entity
Dummy เพือ่ ควบคุม Data Entity
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ประเภทเดียวกัน/กลุ่มเดียวกัน/เป็ นส่ วนหนึ่งส่ วนใด จะให้ Super
Data Entity นั้นแปลงเป็ น Super Type Object)
5. กรณี Weak Entity Type ของ ER Diagram อาจ
พิจารณารวมไว้ ใน Object ใด Object หนึ่ง โดยอาจจะแสดงค่ า
เป็ น Multi Value Attributes หนึ่ง ๆ (ประสิ ทธิภาพต่าและไม่
ยืดหยุ่น)
จากตัวอย่ าง ภาพ ER ข้ างต้ น แปลงเป็ นกลุ่มวัตถุได้ ดงั นี้
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
จากนั้นพิจารณาตามขั้นตอน 2, 3 (ไม่ มี 4, 5) ได้ ผลดังนี้ (ผัง OO)
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ตัวอย่ างข้ างล่ างเป็ น ผัง EER Diagram ซึ่งสามารถดัดแปลงเป็ น
ผัง OO ได้
SSN
BDate
Name
Address
Employee
d
EngType
TypingSpeed
Tgrade
Secretary
Technician
Engineer
ขัน้ ตอนการวิเคราะห์ระบบงานด้วยวิธี CRC
ผังแสดง EER diagram ซึ่งเพิม่ Employee Entity สาหรับควบคุม
กลุ่ม Entity Secretary, Technician และ Engineer
Employee
Name
SSN
BData
Address
Secretary
Technician
Engineer
Typing speed
Tgrade
Eng type
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
หลังจากที่ได้ ทาการวิเคราะห์ ระบบงานเชิ งวัตถุด้วยวิธีการ
OO-A แล้ วสิ่ งที่ได้ จากขั้นตอน 3.1 คือ Object, Class, System,
Architrecture (Subsystem) และ Class Diagram พร้ อมได้ เค้ า
โครงของ Attribute ที่น่าจะเป็ นของ Object/Class ของระะบบ
ส่ วนการกระทา (Method) ยังไม่ ปรากฎในขั้นตอนการทา OO-D
จะเปลีย่ นแปลงสิ่ งที่เป็ นนาม นามธรรม (Logical) ให้ เป็ นรู ปธรรม
(Physical ขึน้ ) วัตถุใหม่ ๆ จะปรากฎขึน้ เช่ น Interface Object
และวัตถุควบคุม (Control Object)
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
โครงสร้ างของโปรแกรมแม่ (Main program) และการบรรยาย
กระบวนการทางานในโปรแกรมย่ อยๆ (ที่ระบุใน Object) เป็ นต้ น
ขั้นตอนการออกแบบระบบงานมีดงั นี้
1. ขั้นตอนการกาหนดรายละเอียดเชิงรู ปธรรมใน Use Case
Description ขั้นตอนนีเ้ ป็ นการนาเอาทุกๆ Use Case Description
มาทาการกาหนดรายละเอียดย่ อยในเรื่องต่ างๆ ได้ แก่
- การระบุจุดเข้ า จุดออกสู่ Use Case ซึ่งจุดนีจ้ ะเกีย่ วข้ อง
กับ Actor
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
- การกาหนดรายละเอียด / ลักษณะสิ่ งเชื่อมต่ อ(Interface)
ว่ าเป็ นสิ่ งใด เช่ น หน้ าจอ (Window) สิ่ งพิมพ์ (Print-out) และแต่
ละสิ่ งมีข้อมูล (Field name) ได้ บรรจุอยู่บนสิ่ งนั้นบ้ าง
- การระบุอุปกรณ์ (Physical Device) เช่ น เครื่ องพิมพ์
เครื่องอ่ าน บาร์ โค้ ด เป็ นต้ น
- การกาหนดข้ อความโต้ ตอบต่ างๆ เช่ น Error Message
หรือข้ อความโต้ ตอบต่ างๆ (Message box) เป็ นต้ น
- การกาหนดแป้ นพิมพ์ (Button) ต่ างๆ
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
- การระบุ/อ้ างอิง กลุ่มของ Use Case ทีจ่ ะถูกแยกออกไป
(Extension Use Case) และการเรียกใช้ Use Case จากแหล่ งอืน่ ๆ
(Abstraction Use Case) ตัวอย่ างของ Use Case Description เชิง
รู ปธรรมดังนี้
จากผัง Use Case Description ต่ อไปนี้ Purchase Order
จะมีลกั ษณะเป็ นหน้ าจอปรากฎ Field name ต่ างๆ ได้ แก่ Line#,
Quantity#, Part#, Description, Price, Extended เป็ นต้ น
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
Use Case – Example
Create New Purchass Order
This use case provides a system user with the ability to create a new purchase order for an existing
customer.
- Choose Customer
1. The system prompts the user for the ID of the customer for which they would like to
create an order.
2. The user enters the desired customer ID and submits the data.
3. The system verifies that the given customer exists, and continues on to the “Display
Order” flow.
- lf the customer doesn’t exist, the user is informed and the use case restarts.
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
-
Display Order
1. The system displays the customer name, code, and shipping address, along with the
(initially empth) purchase order, purchase order total, a cancel button, and forms to
add a part or search for a part by keyword.
The purchase order is an ordered list of line items, each of which consists of the
following data:
1. Line #
2. Quantity
3. Part #
4. Description
5. Price
6. Extended
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
2. The user must now choose to cancel the order (“Cancel Order”), add a part to the order
(“Add Line Item”), search for a part (“Search for Part”), or if the order is not empty,
save the order (“Save Order”)
- Add Line Item
1. The user enters a part number and quantity, and submits the data to be added to the
purchase order.
2. The system retrieves the part’s price and description, adds the part to the end of the
order, calculates the extended price by multiplying quantity by price, and adds the
extended price to the running total, after which the use case returns to the “Display
Order” flow to view the updated purchase order.
- lf the part does not exist, the quantity is not positive or whole, or the purchase order
total exceeds $100,000 the part is not added to the order, and the user is informed of
the error upon returning to the “Display Order” flow.
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
- Search for Part
1. The user enters a keyword to be used in a case-sensitive substring search on part
descruptions, and submits the data.
2. The system retrieves all parts that match, and for each one, displays the part number,
description, and price to the user.
3. If the user chooses a part, the system proceeds to the “Display Order” flow, but
automatically fills in the chosen part number n the part form, so that the user may
proceed with the “Add Line Item” flow as usual,
4. If user does not want to choose a part, the user may return to the order without
choosing a part (“Display Order”), or perform another search (“Search for Part”)
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
- Cancel Order
1. The system completely discards and record of the purchase order and displays a
message confirming that the order has been cancelled.
- Save Order
1. The system chooses the next available purchase order number.
2. The system permanently stores the purchase order using the new number,
automatically choosing the order that was just created.
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
2. ขั้นตอนการระบุประเภทของ Object เป็ นการพิจารณา
ระบุว่าใน Use Case หนึ่งๆ มี Object ใดบ้ าง แต่ ละตัวเป็ นวัตถุ
ประเภทใด ระหว่ าง Interface Object, Control Object และ
Persistent หรือ Data Object ขั้นตอนนี้ ผู้ออกแบบระบบงาน
สามารถแยกแยะได้ โดยสะดวกเนื่องจาก เป็ นผู้กาหนดขึน้ เองจาก
ขั้นตอนที่ 1
Interface Object
Control Object
Entity Object
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
3. ขั้นตอนการระบุ Attribute ของ Object ขั้นตอนนีจ้ ะ
พิจารณาการรวบรวม Attribute ต่ างๆ ที่เกี่ยวข้ องกับ Persistent
Object ( Database Object) ซึ่ง Attribute เหล่ านีจ้ ะนาเข้ าและ
ส่ งออกกับ Object Database โดยตรง หน้ าจอต่ างๆ ที่นาข้ อมูลเข้ า
สู่ Persistent Object นั้น รายงานที่นาข้ อมูลออกจาก Persistent
Object นั้นๆ ข้ อมูลเหล่ านีจ้ ะเป็ น Attribute ต่ อ Entity Object
ทุกๆ ตัวที่ระบุจากขั้นตอนที่ 2 อนึ่ง Entity Object คือ เหล่ า
Object ที่รวบรวมจากขั้นตอนการทา OO-A
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
4. ขั้นตอนการระบุความสั มพันธ์ ของวัตถุ
(Object
Interaction) เป็ นขั้นตอนการแสดงความเกี่ยวข้ องกันระหว่ าง
Actor กับ Interface Object, Control Object and Entity Object
แต่ ละ Use Case มักจะมี Actors ต่ างกันและอาจมี
Interface, control, Entity Object ต่ าง / ร่ วมกันได้
Fill in information
And Submit
Actor:Student
Add course
(Bob, Math 202)
Registration Form
(Interface Object)
Add Bob
Registration Manager
(Control Object)
Math 202
(Entity Object)
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
5. ขั้นตอนการระบุการกระทา (Method) ของ Object
ขั้นตอนนีจ้ ะทาการพิจารณาแต่ ละ Use Case ว่ ามีการกระทา
(Behavior/Method/Function) โดยปรากฏอยู่ในแต่ ละ Use Case
Description โดยใช้ วิธีการหากิริยา (Action Verb Phase) ซึ่ ง
เกี่ยวข้ องกับวัตถุใด และคากริ ยานี้ อาจเป็ นแบบ Manual หรื อ
กระทาโดยโปรแกรม (Automatic) คากริ ยาที่เกี่ยวข้ อง และมี
ลักษณะการทางานแบบอัตโนมัติ จะถูกพิจารณาเป็ น Method ของ
วัตถุทเี่ กีย่ วข้ อง ผลการพิจารณาจะถูกแยกใส่ ตารางดังภาพ
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
Behavior Automatic/Manual Object Type
Object Name
กระทาขั้นตอนขั้นที่ 5 นีก้ บั ทุกๆ Use Case Description จนได้
ตารางระบุการกระทาครบตามจานวน Use Case Descrikption
หลังจากนั้น ให้ พจิ ารณา Behavior ที่เป็ น Manual ออกไปคงไว้
แต่ Automatic สุ ดท้ ายให้ ทาการเกลี่ย Behavior จาก Object
Name นาผลที่ได้ มาสรุ ปรวบรวมไว้ ในตาราง
CRC (Class
Responsibility Corllaboration Card)
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
ซึ่งจะนาเสนอรายละเอียดของ Object ต่ างๆ เมื่อนา Attribute
ของ object นั้นมาบรรจุใน CRC จะได้ Object ที่เต็มรู ปแบบครบ
สามคุณลักษณะคือ ชื่อวัตถุ Attribute และ Method และหาก
Method หนึ่งๆ จาเป็ นต้ องเรียกใช้ ขาน Method จาก Object อืน่ ๆ
ให้ ทาการระบุไว้ ในส่ วนของ Collaborator รู ปแบบของ CRC
แสดงดังนี้ (CRC Template)
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
Front
Class name :
Description :
Responsibilities :
(ด้านหน้า)
ID:
Back
Attributes :
(ด้านหลัง)
Relationship :
Collaborators :
Generalization :
Aggregation
:
Other Association :
Type :
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
6. ขั้นตอนแสดงรายละเอียดของความเกี่ยวข้ องกันของ
วัตถุในแต่ ละ Use Case
ขั้นตอนนีใ้ ช้ แสดงความเกีย่ วข้ องกัน
ระหว่ าง Action, interface Control-Entity Object คล้ ายๆ กับผล
การทางานขั้นตอนที่ 4 แต่ จะแสดงมิติของเวลาการกระทาก่ อน/
หลั ง และการระบุ ช่ วงรั บ ผิ ด ชอบงานของแต่ ล ะวั ต ถุ ผั ง แสดง
รายละเอียดดังกล่ าวเรียกว่ า Object Interaction Diagram and
Sequence Diagram
ผลของการจัดทา Sequence Diagram จะช่ วยแสดง
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
รายละเอียดการทางานย่ อยๆ เป็ นขั้นเป็ นตอน (Scenario) ของแต่
ละ Use Case ว่ าเกี่ยวข้ องกับ Method ของ Object ใดบ้ างมี
เงื่อนไข/การวนซ้า เช่ นไร ผลพลอยได้ ที่สาคัญของการจั ดทา
Sequence Diagram คือได้ Main Program ที่แสดงขั้นตอนการ
กระทา (Perform) /สั่ งการ Method ของ Object ต่ างๆ ให้ กระทา
ตามความประสงค์ ของงานหนึ่งๆ โดยตรง ตัวอย่ างของ Sequence
Diagram เช่ น
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
: Student
: Registration
Form
(Interface)
: Registration
Manager
(Control)
: Math 201
(Entity)
: Math 201
Section 1
(Entity)
1. Fill in info
2. Submit
3. Add course
(Bob, Math 201)
4. Are you open ?
6. Add (Bob)
5. Are you open ?
7. Add (Bob)
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
ในภาพ Actor:Student จะกรอกแบบฟอร์ ม/หน้ าจอใส่ รายละเอียด
ต่ างๆ ลงในใบลงทะเบียน (1) และทาการยืน่ /ป้อนข้ อมูลเข้ าสู่ ระบบ
(2) โดยมี Interface Object:Registration Form ทาหน้ าที่รับ
ข้ อมูลเมื่อ Action กดแป้น Summit ข้ อมูลจะถูกส่ งให้ กบั โปรแกรม
Registration ทาการรับทราบ เมื่อตรวจสอบ Message พบว่ าเป็ น
การ Add Course โดยมี Agreement คือ Bob,Math 201(3)
Control Object จะตรวจสอบว่ า Entity Object:Math 201 เปิ ดใช้
งาน (เปิ ดสอน) หรือไม่ (4) Entity Object:Math 201
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
จะตรวจสอบ Entity ย่ อย Section1 (5) ว่ าเปิ ดหรือไม่ หากเปิ ดสอน
จะแจ้ งให้ Entity Object:Math 201 ยินยอมให้ รับคาสั่ ง Add
(Bob) (6) เข้ าสู่ Entity Object:Math 201 และส่ งต่ อเข้ า Append
ใน Entity Object:Math 201 Section1 ต่ อไป (7)
สั ญลักษณ์
“
” แสดงช่ วงเวลาในการรับผิดชอบภาระกิจหนึ่งๆ ตั้งแต่ ต้น
จนสิ้นสุ ดแต่ ละ Object
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
7. ขั้นตอนในการแสดงรายละเอียดการทางานของแต่ ละ
Object
ขั้นตอนนีจ้ ะช่ วยแสดงรายละเอียดการทางานภายใน
Object หนึ่งๆ ว่ าถูกใช้ งานจากภายนอกด้ วยเหตุการณ์ ใดบ้ าง แล้ ว
วัตถุดาเนินการตอบสนองเช่ นไร หรือเรียกใช้ วตั ถุอนื่ ๆ ภายนอกจะ
กระทาเช่ นไร ผังงานแสดงรายละเอียดการทางานแต่ ละ Object นี้
จะช่ วยให้ ผู้พัฒนาโปรแกรมสามารถพัฒนาโปรแกรมต่ างๆ ความ
เกี่ย วข้ องโปรแกรมต่ างๆ ของวัตถุ หนึ่ งๆ ได้ ห รื อ ใช้ เป็ นเอกสาร
ประกอบวัตถุ (Object Specification)
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
ผังงานทีใ่ ช้ คอื Activity Diagram ตัวอย่ างเช่ น
Request Message Creation
Request Address
Display Error Message
Invalid
Address
Request Verification
nvalid Address
I
Request Subject
Request Text
Notacceptable
Notacceptable
acceptable
Request Delivery
Cancel Message
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
8. ขั้นตอนการจัดทาผัง Class Diagram ที่สมบูรณ์
(Complete Class Diagram ) เป็ นขั้นตอนการนาเอา Attributes,
Methods, Objects ต่ างๆ ที่รวบรวมมาได้ แล้ วบรรจุลงไปใน Class
Diagram พร้ อมแสดงลักษณะความสั มพันธ์ กนั ในรู ปแบบต่ างๆ
(Association, Aggregation)
และขนาดของความสั มพันธ์ กนั
(Multiplicity) ดังภาพตัวอย่ าง Class Diagram
ขัน้ ตอนการออกแบบระบบงานด้วยวิธี CRC
Registration form
Schedule Algorithm
Registration Manager
add student (student
name,Course)
Course
Registration User
Name
Student
Location
Major
Open()
add student
Professor
Course Offering
Tenure Status
Location
Open()
add student