เรื่องราวหลากหลายเทคโนโลยีน่ารู้เพื่อคุณ
Group Blog
 
All Blogs
 

Use Case Diagram ไม่ใช่ Flowchart นะจะบอกให้

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


หลังจากไม่ได้เขียนบล็อกเสียนาน และหลัง ๆ นี้แทบไม่ได้เขียนเกี่ยวกับการพัฒนาโปรแกรมเลย วันนี้ก็ขอเขียนเสียหน่อยแล้วกัน แต่ก่อนอื่นขอเป็นกำลังใจให้กับชาวไทยทุกคนที่กำลังเผชิญกับปัญหาน้ำท่วมอยู่ตอนนี้นะครับสำหรับเรื่องที่ต้องการจะเขียนวันนี้คือเรื่องที่ดูเหมือนจะง่าย ๆ ก็คือการเขียน Use Case Diagram จริง ๆ ผมตั้งใจจะเขียนมาหลายเดือนแล้ว เอหรือจะเกือบปีแล้วก็ไม่รู้ คือผมได้มีโอกาสไปบรรยายเรื่องการพัฒนาโปรแกรมให้กับหน่วยงานหน่วยหนึ่ง ก่อนที่จะบรรยายผมก็ลองให้โจทย์กับผู้อบรมลองเขียน Use Case Diagram ดู ปรากฏว่าผู้เข้าอบรมหลายคนเขียน Use Case Diagram เหมือนกับว่ามันเป็น Flowchart และวันนี้เองสด ๆ ร้อน ๆ กับนักศึกษาในที่ปรึกษาของตัวเองก็ดูเหมืือนว่าจะเข้าใจผิดไปในแนวทางนั้นเช่นกัน ดังนั้นก็เลยคิดว่าคงต้องเขียนบล็อกนี้ขึ้นมาเสียหน่อยเพื่อจะช่วยให้เรื่องนี้ชัดเจนขึ้น

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

จงเขียน UML Diagram สำหรับระบบ ATM ที่่มีการทำงานคือฝากเงิน (Deposit) โอนเงิน (Transfer) และถอนเงิน (Withdraw) โดยจะต้องมีการตรวจสอบตัวตนของลูกค้าด้วย



จากโจทย์ก็เป็นตัวอย่างพื้นฐานทั่วไป แต่มีผู้เข้ารับการอบรมหลายคนเขียน Use Case Diagram ในลักษณะนี้ครับ





Use Case Diagram แบบ Flowchart






ซึ่งผมก็ได้สอบถามว่าทำไมเขาถึงเขียนไดอะแกรม ในลักษณะนี้ คำตอบของเขาก็คือ ก็ทำตามโจทย์อาจารย์ ตรวจสอบสิทธิก่อนที่จะอนุญาตให้ทำธุรกรรมอย่างอื่น จะเห็นได้ชัดนะครับว่านี่คือความเข้าใจผิด ตัว Use Case Diagram ไม่ได้แสดงโฟลว์การทำงานว่าอะไรต้องทำก่อนอะไร อีกจุดหนึ่งที่ผมคิดว่าเป็นปัญหาของไดอะแกรมนี้ก็คือตัว Use Case ของเขาสองตัวคือ Enter Password และ Validate Password นั้นอยู่ในระดับที่ย่อยมากเกินไป

ถึงตรงนี้หลายคนก็อาจตั้งคำถามว่าแล้วเราควรจะเขียนอย่างไรดี ผมไม่ตอบดีไหมนี่ ทิ้งให้คิดเป็นการบ้าน มาเฉลยพรุ่งนี้ สวัสดีครับ ...... :)


ล้อเล่นน่ะครับ เฉลยเลยแล้วกันเดี๋ยวอึดอัดกันแย่ แนวทางหนึ่งที่จะเขียน Use Case Diagram สำหรับปัญหานี้ก็ตามนี้ครับ





Use Case Diagram สำหรับระบบ ATM อย่างง่าย 



จากไดอะแกรมนี้ผมได้รวมเอา Validate Password และ Enter Password เข้าด้วยกันเป็น Use Case ที่ชื่อว่า Authenticate และใช้ความสัมพันธ์  include เพื่อแสดงให้เห็นว่า Use Case ที่เหลือทั้งสามนั้นจะต้องมีการตรวจสอบตัวตนของผู้ถือบัตร ไดอะแกรมนี้แสดงความต้องการของระบบตรงตามที่โจทย์กำหนดได้อย่างชัดเจน และ Use Case Diagram ได้ทำหน้าที่หลักที่มันควรจะทำนั่นคือการแสดง Functional Requirement ของระบบ ไม่ได้แสดงโฟลว์การทำงาน อย่าลืมนะครับว่า Use Case Diagram เรามักจะสร้างขึ้นในช่วงวิเคราะห์ระบบ ซึ่งการวิเคราะห์ระบบควรจะตอบคำถามว่า "what" ซึ่งหมายความว่าระบบนี้ทำอะไรให้ได้เสียก่อน ไม่ใช่ไปตอบคำถามของคำว่า "how" ซึ่งหมายถึงว่ามันทำงานอย่างไร ถ้ามีแนวคิดนี้อยู่ในใจตลอดก็น่าจะหลีกเลี่ยงการเขียน Use Case Diagram ในลักษณะที่เป็น Flowchart ได้

หวังว่าบล็อกนี้จะทำให้มีความชัดเจนเกี่ยวกับ Use Case Diagram มากขึ้นไม่มากก็น้อยนะครับ ...


คำสำคัญ: Requirement Analysis, Software Development, Use Case Diagram




 

Create Date : 08 ธันวาคม 2554    
Last Update : 8 ธันวาคม 2554 19:31:40 น.
Counter : 3208 Pageviews.  
Share

การพัฒนาโปรแกรมแบบเรียงลำดับกำลังจะตาย!

การคำนวณแบบเรียงลำดับกำลังจะสูญพันธ์ และอนาคตก็คือการคำนวณแบบขนาน" วันนี้ผมขอเริ่มบทความด้วยคำกล่าวของ Dave PAtterson ซึ่งเป็นหัวหน้าห้องปฎิบัติการการคำนวณแบบขนานที่มหาวิทยาลัยแคลิฟอร์เนียที่เบิร์กเลย์ ซึ่งได้กล่าวไว้ในงานสัมมนาทางวิชาการที่ชื่อว่า Usenix Conference อ่านแล้วรู้สึกยังไงครับ ตกใจ แปลกใจ ไม่เห็นด้วย เฉย ๆ หรือว่าเห็นด้วย

เอาละครับ เราลองมาดูรายละเอียดกันดูดีไหมครับว่าทำไมเขาจึงกล่าวเช่นนี้ ซึ่งจริง ๆ ความคิดของเขาก็มาจากการที่การพัฒนาของตัวหน่วยประมวลผลในปัจจุบันนี้ซึ่งเป็นแบบหลายแกน (multi cores) กันแล้วนั่นเอง ซึ่งแน่นอนครับว่าถ้าเราต้องการจะใช้ประโยชน์จากจุดนี้เราก็ต้องพัฒนาโปรแกรมในแบบขนาน

อย่างไรก็ตามศาตราจารย์ Andrew S. Tanenbaum (รู้จักไหมครับ เจ้าพ่อด้านระบบปฏิบัติการคนหนึ่งที่พัฒนา Minix ขึ้นมาเพื่อใช้ในการสอนระบบปฏิบัติการ เป็นแรงบันดาลใจให้ Linus ไปพัฒนา Linux) ได้กล่าวติงว่าการพัฒนาโปรแกรมแบบเรียงลำดับนั้นก็ยากอยู่แล้ว การพัฒนาโปรแกรมแบบขนานยิ่งยากไปกว่านั้นอีก เขาเกรงว่าถ้าเราเขียนโปรแกรมให้ทำงานไปพร้อม ๆ กันบนแกนเหล่านี้ โปรแกรมที่พัฒนาขึ้นจะเลวร้ายลงไปอีก ซึ่ง Patterson ก็เห็นด้วยในเรื่องนี้ว่าเรายังขาดบุคลากรทางด้านนี้อยู่จริง ๆ

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

แต่ผมเป็นห่วงเรื่องของบุคลากรเช่นกันครับ ยิ่งเห็นนักศึกษาบางคนอยู่จนปีสามหรือปีสี่แล้วยังเขียนโปรแกรมกันไม่คล่อง ขั้นตอนวิธี โครงสร้างข้อมูลพื้นฐานก็ยังไม่ค่อยจะเข้าใจกัน ดังนั้นต้องฝากพวกเราโดยเฉพาะที่กำลังเรียนอยู่นี่จะต้องตั้งใจเรียนการพัฒนาโปรแกรมให้เข้าใจอย่างลึกซึ้ง จากนั้นถ้าเห็นแนวโน้มนี้แล้วก็น่าจะเลือกวิชาเช่นขั้นตอนวิธีแบบขนานไว้เป็นวิชาเลือก และคิดว่าในอนาคตก็คงต้องมีการปรับปรุงหลักสูตร โดยให้มีวิชาที่เกี่ยวกับการพัฒนาโปรแกรมแบบขนานเป็นวิชาบังคับ และมีวิชาเลือกให้มากขึ้น


คำสำคัญ


การเขียนโปรแกรม, การเขียนโปรแกรมแบบเรียงลำดับ, การเขียนโปรแกรมแบบขนาน

อ้างอิง


ที่มา SearchDataCenter.com เข้าอ่านล่าสุด 21ธ.ค. 2551




 

Create Date : 26 กรกฎาคม 2551    
Last Update : 21 ธันวาคม 2551 11:36:18 น.
Counter : 693 Pageviews.  
Share

ภาษาโปรแกรมสำหรับยุคต่อไป

หลังจากบทความที่ผ่าน ๆ มา เป็นการเล่าเรื่องทางไอทีที่น่าสนใจให้ฟัง บทความนี้ก็ขอเขียนเกี่ยวกับการพัฒนาโปรแกรมบ้างนะครับ
ที่มาของบทความนี้ก็คือ ผมเคยได้รับคำถามจากนักศึกษาว่าเขาควรจะศึกษาภาษาโปรแกรมอะไรดี ซึ่งผมก็ได้ตอบไปว่าให้เรียนภาษาที่สอนกันที่คณะ (Java) ให้เข้าใจแนวคิดการเขียนโปรแกรม แล้วจะสามารถนำไปประยุกต์กับภาษาอื่น ๆ ได้โดยไม่ยาก พอดีวันนี้ได้ไปอ่านบทความนี้ครับ //www.infoworld.com/article/08/06/23/26NF-dynamic-scripting_1.html เห็นว่าน่าสนใจดี และเกี่ยวข้องกับที่นักศึกษาเคยถามก็เลยเอามาเล่าให้ฟัง ในบทความเขาบอกว่าภาษาสคริปต์จะเปิดยุคใหม่ของการเขียนโปรแกรมครับ ซึ่งเขาเรียกว่า programming to the masses ครับ ซึ่งผมก็ขอแปลว่าการโปรแกรมเพื่อมวลชนครับ :) ซึ่งผมเข้าใจว่าเขาจะเน้นว่าภาษาสคริปต์พวกนี้เขียนได้ง่าย ดังนั้นน่าจะมีผู้คนที่เขียนภาษาเหล่านี้เป็นกันมากขึ้น โดยภาษาสคริปต์ที่ใช้กันบนฝั่งไคลแอนต์ส่วนใหญ่ก็จะเป็น JavaScript ส่วนภาษาสคริปต์บนฝั่งเซอร์ฟเวอร์ก็จะเป็น PHP ซึ่งผู้ที่อยู่ในวงการคอมพิวเตอร์ก็คงเห็นนะครับว่า ก็ไม่ใช่ภาษาใหม่อะไรเลย แต่เป็นภาษาที่เรารู้จักกันมานานแล้ว ซึ่งเหตุผลหลัก ๆ ในความเห็นของผมเป็นดังนี้ครับ ประการแรกก็คือความแพร่หลายของการใช้เว็บเป็นแพลตฟอร์มในการพัฒนาระบบ ความแพร่หลายของเว็บเซอร์วิส ประสิทธิภาพที่เพิ่มขึ้นของคอมพิวเตอร์ และคุณลักษณะบางอย่างที่ทำให้ผู้พัฒนาโปรแกรมรู้สึกว่าการพัฒนาโปรแกรมทำได้ง่ายขึ้น เช่นการที่ตัวแปรเป็นแบบไดนามิก คือสามารถเปลี่ยนประเภทไปได้ตามประเภทข้อมูลที่ใช้ในขณะนั้น (แต่อันนี้ก็แล้วแต่คนชอบนะครับ บางคนอาจไม่ชอบคุณลักษณะที่เป็นไดนามิกแบบนี้ก็ได้) นอกจากสองภาษานี้แล้วก็ยังมีภาษาอื่น ๆ ที่น่าสนใจที่แนะนำในบทความครับเช่น python และ Ruby ถึงตรงนี้แล้วหลายคนก็อาจมีคำถามว่าถ้าอย่างนั้นภาษา Java ภาษา C ภาษา C++ นั้นไม่จำเป็นแล้วใช่หรือไม่ ซึ่งผมก็คงต้องตอบว่าไม่ใช่ ในความเห็นผมภาษาสคริปต์ต่าง ๆ เหล่านี้ เหมาะสมกับการทำงานในลักษณะที่จะเป็นตัวเชื่อม โดยเรียกใช้คอมโพเนนต์ต่าง ๆ ที่มีอยู่มาใช้งานร่วมกัน ส่วนคอมโพเนนต์ต่าง ๆ เหล่านี้ก็ยังคงจะต้องพัฒนาโดยใช้ภาษาหลัก ๆ อยู่ดี ซึ่งตามหลักการของการพัฒนาระบบแบบคอมโพเนนต์นั้น จะมีอยู่สองส่วนด้วยกันคือการพัฒนาเพื่อนำกลับมาใช้ใหม่ (development for resue) และการพัฒนาโดยนำสิ่งที่มีอยู่แล้วมาใช้ (development with reuse) ภาษาอย่าง C++ หรือ Java ก็จะใช้ในการพัฒนาส่วนแรก ส่วนภาษาสคริปต์เหล่านี้ก็จะอยู่ในส่วนที่สอง ในส่วนของบทความผมเห็นด้วยในส่วนที่ว่ามีความเป็นไปได้ที่ภาษาเหล่านี้โดยเฉพาะส่วนที่อยู่บนฝั่งไคลแอนต์ จะกลายมาเป็นภาษาหรับมวลชนจริง ๆ ลองสังเกตุจากพวก Social Web เช่นพวก Hi5 หรือ bloggang ดูนะครับ ตอนนี้ผู้ใช้ทั่ว ๆ ไป เริ่มรู้จักการเขียนภาษา HTML แล้ว โดยอาจจะเริ่มต้นจากการคัดลอกจากเว็บอื่นมาใส่เว็บตัวเอง จากนั้นก็เริ่มศึกษาแล้วก็สามารถเขียนโค้ดของตัวเองได้ ซึ่งผมคิดว่าก็อาจจะเกิดขึ้นได้กับภาษาอย่าง JavaScript เช่นกัน

ดังนั้นก็ฝากไว้ครับโดยเฉพาะกับลูกศิษย์ผม (ซึ่งอาจหลงเข้ามาอ่าน) ครับว่า ต่อไปผู้ใช้ทั่ว ๆ ไปก็อาจจะเขียนโปรแกรมกันได้แล้ว ส่วนพวกที่เรียนกันมาทางสายคอมพิวเตอร์โดยตรงแล้วยังเขียนโปรแกรมไม่ได้นี่ก็... ลองเติมกันดูเองนะครับ




 

Create Date : 28 มิถุนายน 2551    
Last Update : 28 มิถุนายน 2551 23:01:24 น.
Counter : 437 Pageviews.  
Share


motokop
Location :


[Profile ทั้งหมด]

ฝากข้อความหลังไมค์
Rss Feed
Smember
ผู้ติดตามบล็อก : 2 คน [?]

สวัสดีครับ สำหรับบล็อกนี้ผมก็ตั้งใจจะให้เป็นข่าวสารที่น่าสนใจทางคอมพิวเตอร์ ทั้งข้อมูลด้านเทคโนโลยีที่น่าสนใจ การพัฒนาโปรแกรม และงานวิจัยต่าง ๆ อาจแทรกไปด้วยเรื่องอื่นๆ บ้าง ตามแต่อารมณ์และสถานการณ์ครับ ยินดีรับความคิดเห็นของทุกคนครับ
Visit InfoServe for backgrounds.

เพื่อนที่กำลังชมบล็อก:

ผู้ชมทั้งหมด:

Friends' blogs
[Add motokop's blog to your web]
Links
 

 Pantip.com | PantipMarket.com | Pantown.com | © 2004 BlogGang.com allrights reserved.