เริ่มเรียนปีหน้า วันที่ 2 ม.ค. 51

พุธที่ 2 มกราคม 2551 กลับมาเรียนวิชา Business S/W Requirements Analysis ตามปกตินะครับ
สลับคลาสเล็กน้อยระหว่างคลาส อ.สม กับ อ.อัษ วันอังคารที่ 15 มกราคม 2551 เรียนของ อ.สม ส่วนวันพุธที่ 16 มกราคม 2551 ไหว้ครู ก่อนครึ่งชั่วโมงแล้วฟังบรรยาย OO จากวิทยากร ไม่ได้ให้ฟังเฉย ๆ ครับ อ.อัษ บอกว่าฟังเพื่อให้เกิดไอเดีย เพราะ Project II จะต้องหาหัวข้อที่สนใจเกี่ยวกับ OO มาทำรายงาน ส่งก่อนสอบปลายภาค (ประมาณปลายเดือน กุมภาพันธ์)

รวมมิตร อับเดต ก่อนสอบกลางภาค

สวัสดีครับ คิดว่าคงไม่กวนเวลาที่ง่วนอยู่กับการทำ Project Adv. DBMS ที่ต้องส่งกันวันที่ 27 ธันวาคม นี้นะครับ อ่อ ก่อนอื่นต้องขอขอบคุณที่ไปเลือกตั้งกันด้วยนะครับ ... ถึงตอนนี้ก็ไม่รู้ว่าหน้าตารัฐบาลใหม่จะเป็นอย่างไร แต่เฮียขอเดาว่า พวกเรา ๆ คงบอกว่า เอาไว้ก่อนเถอะเรื่องนั้น ขอทำ project ให้ทัน แล้ว ก็อ่านสอบของ อ.สม ในวันที่ 26 ธันวาคมนี้ให้ทันก็พอแล้ว ... ก่อนสอบมีหลายเรื่องมาอับเดตกันหน่อยนะครับ

1. สอบกลางภาค
สำหรับปีนี้ ปิดศักราชด้วยการสอบของ อ.สม วันที่ 26 ธันวาคม นี้นะครับ คงไม่พ้น DFD
สำหรับปีหน้า 51 ของ อ.อัษ วันที่ 8 มกราคม คงแบบ Assignment ทำทันไม่ทันว่ากันอีกเรื่อง
ตามด้วย วันที่ 10 มกราคม ของ Adv.DBMS คงหนี้ไม่พ้น ERD / SQL เฮียแอบไปถามหลังเลิก ไม่ได้แอบถามหรอก บังเอิญเก็บของอยู่ อาจารย์จะออกจากห้องเลย อดถามไม่ได้ แนวข้อสอบ ก็คง Case แล้ว ให้ออกแบบ Database ส่วน DBA ก็จะเป็น Case มาแล้วให้เราแก้ปัญหา (อันนี้น่าลำบากใจ) แต่จากการถาม พี่กบ บอกว่า ไม่ยากหรอก ก็พวกคำสั่ง ALTER อะไรพวกนี้ แต่เฮียว่า DBA คงเป็นอันดับรอง ๆ ลงมา คงเน้นที่ ERD กับ SQL ส่วน หลังสุด วันที่ 13 มกราคม ของ อ.ถาวร แนะแนวข้อสอบว่า ออกเป็น Case เช่นกัน ออกบทที่ 10, 11, 12, 13, 15 ก็เป็น Case ธุรกิจอะไรสักอย่าง แล้วให้เราวาด DFD และ ER โดยประยุกต์จากที่เรียนไป อาจมีลดเพิ่ม ตามแต่โจทย์จะระบุอะไรเป็นพิเศษ ไม่ต้องตกใจนะครับสอบวันอาทิตย์ แต่วันเสาร์ที่ 5 และ 12 มกราคม เรียนตามปกติครับ

สรุปว่า ทุกวิชาเป็น Case ทุกวิชา มึนตอนสอบเข้ามายังไง ก็จงมึนต่อไปแบบนั้นทุกวิชา เอิ๊ก ๆๆๆๆ

"เรียนแค่จำไปสอบย่อมเป็นทุกข์ เรียนให้สนุกคือการประยุกต์ไปใช้"

2. หนังสือธรรมะ

นายป๊อป อาสามาบอกบุญ โดยป๊อปมีโครงการที่ทำกับเพื่อน ๆ ป๊อป พิมพ์หนังสือธรรมะแจกเป็นธรรมทาน เห็นบอกว่า เป็นบทแผ่เมตตา ค่าจัดพิมพ์เล่มละ 8 บาท บริจาคได้ที่ป๊อปตามกำลังศรัทธา เฮียดูแล้วครับ รูปเล่มพิมพ์สวยเก๋ไก๋ แบบหนังสือกลอนวัยรุ่น มีการ์ตูนประกอบ งานนี้มีสาว ๆ อึ้งไปเล็กน้อย เพราะไม่คิดว่าหนุ่ม ๆ ในห้องจะมีจิตใจใฝ่ธรรมะ ซะขนาดนี้ เรื่องดีๆ แบบนี้ต้องสนับสนุนนะครับ เผื่อบุญจะหนุนนำให้ทำข้อสอบได้ พกเข้าห้องสอบไม่ผิดกฏ open book ครับ ฮ่า ฮ่า ฮ่า และเป็นมงคลชีวิตในช่วงปีใหม่นะครับ

3. ของขวัญปีใหม่

เทศกาลส่งความสุขมาถึง ก็เลยมีความคิดกันในห้องนะครับว่า จะซื้อของขวัญปีใหม่ให้อาจารย์แต่ละท่านที่สอนเราในเทอมนี้ รวม 4 ท่านที่ประสิทธิประสาทวิชาให้พวกเรา และเจ้าหน้าที่ภาควิชาสถิติ รวมถึงคุณป้า ที่ดูแลเรื่องจัดเครื่องดื่ม และอาหารการกิน และกลับดึกพร้อมพวกเราเสมอมา ส่วนอาจารย์ทุกท่านที่สอนปรับพื้นเราเดี๋ยวดูงบก่อนนะครับ งานนี้เฮียเลยขอเก็บ คนละ 100 บาท ถ้วน โดยให้แต่ละกลุ่มรวบรวม แล้วส่งให้ กิ๊ป นางนพฯ และเหรัญญิก ก่อนปีใหม่นะครับ เพื่อจะได้ไปจัดหาซื้อของต่อไป ส่วนเงินที่เหลือ ก็จะเก็บสมทบทุนเข้ากองกลางของรุ่นต่อไปครับ

ขอบคุณที่สละเวลาอ่านนะครับ กลับไปปั่นงาน และอ่านหนังสือกันต่อไปได้หละครับ ขอให้โชคดี

MERRY X' MAS
&
HAPPY NEW YEAR

BSD ปีใหม่ 51 + ไหว้ครู

งานปีใหม่ '51
หลังจากที่ อ.สมจารี ได้เปรย ๆ เกี่ยวกับการจัดงานปีใหม่ รวมรุ่น BSD ตอนแรกตามที่แจ้งมาเป็นวันที่ 4 มกราคม 51 แต่ด้วยเหตุว่า ช่วงนั้นรุ่นเราคงไม่คิดอะไรนอกจากเตรียมตัวสอบกลางภาค ในวันที่ 8 10 และ 13 มกราคม ตามที่แจ้งไปแล้ว เฮียได้คุยกับนักข่าวสาวของรุ่นพี่ BSD ONE แล้ว และคิดว่า วันเสาร์ที่ 19 มกราคม ในช่วงบ่ายแก่ ๆ หลังจากที่รุ่นพี่ BSD ONE เลิกเรียนแล้ว และรุ่นเราก็หมดห่วงเรื่องสอบไปแล้ว น่าจะโล่ง และอยากระบายความเครียด ที่หลงติดค้างอยู่ ด้วยการฮาเฮ น่าจะเป็นเวลาที่ลงตัวกว่า แม้ว่าจะเริ่มตอนเย็น ๆ หน่อย เฮียคิดว่าไม่น่ามีปัญหาสำหรับรุ่นเรานะครับ เพราะปกติก็ไม่เห็นจะกลับบ้านกลับช่อง นั่งทำ Assignment กันต่อ หลังเลิกเรียนวันเสาร์

Concept งานที่เฮียเสนอไป
เฮียเสนอว่า น่าจะเป็นสวยแต่ฮา คือมีการจับสลาก ห่อส๊วยสวย แต่พอแกะของมาฮาขี้แตกขี้แตน คือเน้นสนุกสนาน ไม่เน้นมูลค่า เก็บตังค์ไว้เรียนมีประโยชน์กว่า แต่เงินเหลือเดี๋ยวเอาเลขที่บัญชีเฮียไปแล้วโอนมาได้ครับ ยินดีรับใช้ครับ ... แล้วมีประกวดห่อของขวัญให้โหวต 2 ประเภทรางวัลคือ "เลิศหรูดีดี" หรือแบบ "สร้างสรรค์มันทำไปได้" ส่วนผู้ร่วมงานก็มายกแก๊งค์ แต่งตัวแบบมีธีม แอนด์ คอนเซ็ปต์ ให้ไปคิดมา เช่น ทีมลูกเสือ เนตรนารี, ยามและแม่บ้าน แล้วแต่เอาว่ามีแนวคิดการออกแบบ (Fashion Engineering เกี่ยวอะไรกันคร๊าบบ งง) เป็นเพียงแนวคิดของเฮีย แล้วจะไปปรึกษาพวกเราอีกที เผื่อมีไอเดียเจ๋งๆๆ

ไหว้ครู
อ่อ ก่อนงานปีใหม่ เกือบลืม ว่าคงจะมีพิธีไหว้ครู ในวันพุธที่ 16 มกราคม 51 สักครึ่งชั่วโมงก่อนเรียนวิชาของอาจารย์สมจารี ก็จะไหว้ครูรวมกันทั้งรุ่นเรา และรุ่นพี่ เนื่องจากวันที่ 16 มกราคม 51 เป็นวันครูครับ

... ดอกไม้วันครู ...

คณะกรรมการจัดงานวันครู พ.ศ. 2539 ได้มีมติกำหนดให้ดอกกล้วยไม้เป็นดอกไม้ประจำวันครู โดยพิจารณาเห็นว่าลักษณะของดอกกล้วยไม้มีลักษณะและความหมายคล้ายคลึงกับ งานจัดการศึกษาและสภาพชีวิตครู ดังคำกลอนของท่านหม่อมหลวงปิ่น มาลากุล ที่ว่า ... " กล้วยไม้ออกดอกช้า ...ฉันใด การศึกษาเป็นไป ...........เช่นนั้น แต่ดอกออกคราวใด ......งามเด่น งานสั่งสอนปลูกปั้น........เสร็จแล้วแสนงาม" นอกจากนี้ กล้วยไม้เป็นพืชที่อยู่ในที่สูง ทนต่อสภาพดินฟ้าอากาศไม่ร่วงโรยง่าย เปรียบเสมือน ครูที่อยู่ทั่วแดนไทย ที่ต้องอดทนต่อสู้เพื่ออุดมการณ์และอุทิศตนเพื่อการศึกษาของชาติ

ส่วนรายละเอียดกำหนดการที่แน่นอนอย่างไรนั้นจะกลับมาเล่าสู่กันฟังอีกทีครับ

งดเรียน ส. 29 ธ.ค. และกำหนดสอบกลางภาค

อีก 1 สัปดาห์ก็เข้าสู่สัปดาห์ของการสอบแล้วนะครับ อ่ออย่าลืมไปเลือกตั้งกันในวันที่ 23 ธันวาคม 50 นี้ด้วย ก่อนจะไปเลือกตั้ง ก่อนจะหยุดปีใหม่ และเปิดศักราชใหม่ด้วยการมาสอบกัน มีข่าวแจ้งกำหนดสอบกลางภาคดังนี้ครับ

วันพุธที่ 26 ธันวาคม 50: 18.00-21.00 น.
2603683 Business Software Requirements Analysis

วันอังคารที่ 8 มกราคม 51: 18.00-21.00 น.
2603672 Object-Oriented Technology

วันพฤหัสบดีที่ 10 มกราคม 51: 18.00-21.00 น.
2603688 Advanced Database Management System

วันอาทิตย์ที่ 13 มกราคม 51: 9.30-11.30 น.
2603570 Business Information System

* วันเสาร์ที่ 29 ธันวาคม 50งดเรียน
* วันเสาร์ที่ 12 มกราคม 51 เรียนตามปกติ

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

Design Pattern 4 กลยุทธ์วางแผนรบ ใน OO ยุทธภพ

หลายคนคงอาจจะก๊งๆๆ เอ๋อ ๆ กันอยู่ว่า อะไรครับ อะไรคะ คุณพี่ ช่วงนี้ไม่มีกระจิตกระใจจะทำอะไรนอกจาก Assignment ที่หิน ๆ ของแต่ละวิชา แล้วไหนจะวันสอบที่ใกล้เข้ามาอีก กลัวจะอ่านหนังสือไม่ทันจริ๊ง ๆๆๆ สู้ต่อไปครับ (บอกตัวเองด้วย เฮ้อๆๆๆ)

ว่ากันด้วยวิชาที่สุดแสนจะกังวลของหลาย ๆ คน คือ OO เพราะแม้ว่ามันจะพยายามบอกว่า represent real world แต่ให้ตายเหอะมันเข้าใจย๊ากยาก ไม่เห็นจะเหมือนชีวิตจริงตรงไหน อะ เฮียนอกเรื่องไปไกล วกเข้าเรื่องตรงประเด็น เลยดีกว่า วันนี้หลังจากเอาไฟล์บรรยายเสียงที่ ชาย อัดไว้ให้ทุกครั้งมานั่งเปิด ก็เลยคิดว่าจะสรุปแบบไม่ได้คิดเอง ตัดมาเฉพาะเรื่อง Design Pattern ว่าแต่ว่า เฮียกำลังสอนตัดเย็บเหรอ กำลังสอนดีไซน์ แพทเทิร์นเสื้อผ้าเหรอ ... สาธุใครคิดแบบนี้ขอแช่งให้สอบผ่าน แบบผ่านไปเลย ไม่ต้องเจอกันอีก

แล้วดีไซน์ แพทเทิร์น มันคืออะไร?
จริง ๆ มันก็คือการออกแบบคำสั่ง อะอะ หยุดเลย อย่าเพิ่งไปคิดถึงคำสั่งโปรแกรม คือ มันก็คือการออกแบบทางเดิน วางแผน การคิดอย่างมีระบบ ว่าจะใช้ใคร (คลาส) ทำอะไร จะเอาข้อมูลมาจาก (คลาส)ไหน โดยที่มันก็มีหลักการพอเป็นแนวทาง เออ ต้องบอกก่อนนะว่า เรื่อง Design Pattern เขาพูดหลังจากที่เราได้ Class Diagram มาแล้ว ที่มัน (คลาส) โยงกันไปโยงกันมา มันก็คือความสัมพันธ์ คราวนี้หละพอมัน (คลาส) มีความสัมพันธ์กัน ... อย่าลืมนะ ว่าคลาสมันมีชีวิตจิตใจ คิดได้ แสดงพฤติกรรมได้ แถมสร้างลูกหลาน instance มาเพล่นพล่านได้ด้วยนะ ..เปรียบได้ดั่งคนเรานี่หละ... ก็ต้องอาศัยคัมภีร์พิชัยสงคราม ขงเบ้ง คอยเป็นไกด์ว่าจะใช้ขุนพล (คลาส) ตัวไหน ให้ทำอะไร งานถึงจะบรรลุตามเป้าหมายในแต่ละงาน (Trigger) อย่างแยบยล เพื่อบรรลุภารกิจ (Use Case) ที่ได้รับมอบหมาย

เอาไปใช้ทำอะไรหละเจ้า Design Pattern?
ตอบสั้น ๆ ถ้าสอบ ก็บอกว่า เอาไว้เป็นไกด์ช่วยเชียน Interaction Diagram หือ อะไรอะ รู้จักแต่ Sequence Diagrm อือใครตอบแบบนี้ แสดงว่าโดดบ่อย Interaction Diagram = Sequence Diagram + Communication Diagram ครับกระผม ถ้าไม่รู้จักศัตรูและขุนพลแห่งตน (คลาสทั้งหลายไง) และกลยุทธ์แห่งศึกสงคราม (ดีไซน์แพทเทิร์นไง) อย่าริอาจวางแผนรบ (อย่าเขียน Sequence Diagramไง)

4 กลยุทธ์วางแผนรบ ใน OO ยุทธภพ
Design Pattern 4 กลยุทธ์วางแผนรบ ใน OO ยุทธภพ แห่งสำนัก BSD ณ หุบเขา IT Studio ยอดที่ 9
อาจารย์ข้ากล่าวว่า จักทำการใหญ่ ในสมรภูมิแห่ง OO ยุทธภพ ที่เต็มไปด้วย Class มากมายนั้น เจ้าต้องรู้จักมันให้ลึกซึ้งถึงสายสัมพันธ์ (association) ที่ Class เหล่านั้นมีต่อกันให้ถ่องแท้เสียก่อน แล้วเจ้าจงเลือกใช้ กลยุทธ์แห่งข้าไปใช้ เจ้าจะได้รับผลแห่งชัยชนะที่เจ้าพึงประสงค์ในที่สุด

กลยุทธ์ที่ 1 : ผู้สร้าง (Creator)
เจ้าจงจำว่าในยุทธภพแห่ง OO คลาสบางตัว มันมิอาจเกิดขึ้นเองได้ มันต้องอาศัย คลาส ที่เหนือกว่า หรือบางทีมันก็เป็นบริวาร (is a part) ของคลาสหลัก ที่มีบุญคุณกันอย่างเหนียวแน่น บางทีมันก็เป็นทายาทกัน บางทีมันก็อุปการะกัน บางทีก็สามีภรรยากัน คลาสเยี่ยงนี้เจ้าจักจำไว้ เจ้าคลาสลูกๆ หรือคลาสบริวารเหล่านี้ เจ้ามิต้องเสียเวลาไปเจรจากับมัน จงเข้าหาคลาสพ่อและแม่ หรือคลาสผู้มีอุปการะคุณแห่งมันก็พอ จักให้มันสั่งการกันเอง

Sales --creates--> Sale line items

กลยุทธ์ที่ 2: ม้าเร็ว (Informaion Expert)
คลาส ในยุทธภพ OO บางคลาสแม้จะไม่ได้มีความสัมพันธ์แนบแน่นที่มีบุญคุณต่อกัน แต่ก็เสมือนมิตรแห่งกันที่ไปมาหาสู่กันเป็นประจำ เข้านอกออกในคุ้นเคยกันดีอยู่ เจ้ามิต้องคิดเสียเวลาไปติดต่อทุกคลาส เจ้าจงยืมม้าเร็วในคลาสที่เจ้ารู้จัก ให้อาสาไปนำสิ่งที่ต้องการจากคลาสแห่งเพื่อนของเขาที่เจ้ามิคุ้นเคยมาให้เจ้าเถิด มิจักต้องเสียเวลาแห่งการเจรจา เพื่อนย่อมเข้าใจเพื่อนของเขาได้ดีกว่าคนนอก จงใช้เพื่อนไปหาเพื่อน อย่าจักใช้คนนอกที่เขาไม่คุ้นเคยไปเจรจาเลย

Sales --สร้าง--> Sale line items <-- อธิบาย-- Product Desc.

คกลยุทธ์ที่ 3: สมานฉันท์ (Low Coupling)
คลาส ในยุทธภพ OO จักมีธรรมเนียมปฏิบัติต่อกันอยู่อย่างเคร่งครัด แม้ความสัมพันธ์แห่งกันจะสามารถสร้างใหม่ได้ แต่กระนั้น เจ้าจงพิจารณาดูธรรมเนียมปฏิบัติทั่วไปที่เขานิยมให้ถ่องแท้ แล้วเดินตามธรรมเนียมปฏิบัตินิยมนั้น อย่าริคิดสร้างธรรมเนียมปฏิบัติของเจ้าเอง แม้นเจ้าจักทำได้ก็จะเป็นการสร้างความวุ่นวายในยุทธภพแห่ง OO ด้วยเช่นกัน

Sales -- สร้าง --> Payment

Register --สร้าง --> Payment
(ทำได้แต่ไม่ Low coupling เพราะ register รองรับ connect เยอะมากอยู่แล้ว)

กลยุทธ์ที่ 4: พระราชา (Controller)
แคว้นทุกแคว้นย่อมมีปกครองด้วยพระราชา คลาสในยุทธภพ OO ก็เช่นกัน หากเจ้าพึงประสงค์จักเข้าถึงทุกคลาสแล้ว เจ้าจงเข้าหาพระราชาผู้ปกครองแคว้นแห่งคลาสนั้นเสียก่อน หากแคว้นแห่งคลาสเหล่านั้น มิได้มีคลาสใดเป็นผู้ปกครอง เจ้าจงตั้งตนเป็นพระราชา รวบรวม ปกครองสมานฉันท์เอาคลาสเหล่านั้นเสีย

POS, Register, CarRentalSystem etc.

พิชัยยุทธ์มิอาจจักเป็นประโยชน์ได้ หากไม่เคยล่วงรู้การเอาไปใช้ อาจารย์หญิงแนะนำว่า หากเจ้าเลือกใช้กลยุทธ์ทั้งสี่นี้ จะเข้าไปตีแคว้นใด เจ้าจงเลือกที่จะมองพระราชาเสียก่อน (Controler) แล้วมุ่งไปที่คลาสที่เป็นครอบครัว (Creator) เลือกดูคลาสที่เป็นเพื่อนกันเพื่อใช้ม้าเร็ว (Information Expert) แล้วจงพิจารณาเอาทางที่ง่าย และสับสนน้อยที่สุด (Low Coupling) ตามลำดับ เจ้าจักได้รับชัยชนะในการรับมือกับคลาสในยุทธภพ OO


OO in Real World พอหรือยังครับ ...?
แค่อยากให้อ่านสนุก ๆ แบบให้เข้าใจธรรมชาติของ OO ในแบบชีวิตจริงครับ ส่วนเรื่องของรายละเอียดทีถูกต้องตามหลักวิชาการ หาอ่านได้จากในเอกสาร และตำราทั่วไป มีความคิดเห็นอย่างไร แนะนำทิ้งกันไว้ได้ครับยินดีน้อมรับทุกคำแนะนำครับ

เขาสร้าง Class Diagram กันอย่างไร

ไป search หาข้อมูลเล่นๆ นานๆ ทีจะมีคนไทยเขียนบทความเกี่ยวกับ Object-Oriented เลยเก็บมาฝากกันครับ

เรื่องนี้คนสนใจกันมาก เป็นเรื่องน่ายินดีครับ แสดงว่าเราเริ่มเข้าสู่กระบวนการใหม่ในการพัฒนา Software จากเดิมที่ออกแบบกันโดยใช้ DFD (Data Flow Diagram) และ ER Diagram มาเป็น UML แต่แน่ๆ ครับ การปรับเปลี่ยนครั้งนี้คงไม่ง่ายนัก อาจต้องตีลังกาคิดกันบ้าง แต่ไม่เป็นไรครับเรามีตัวช่วยที่ปรมาจารย์ทั้งหลายคิดค้นกันขึ้นมา วันเรามาดูรายละเอียดกัน

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

แค่นึกเป็น Class แล้ว

มีคนอยู่พวกหนึ่งครับ พอได้รับโจทย์แล้วฟังไปก็จินตนาการเป็น Class ต่างๆ ได้เลย หรือไม่หลังการคุยกับผู้ใช้ ก็สามารถสร้าง class ได้เต็มไปหมด พวกนี้ไม่มีอะไรมากครับ แก่ประสบการณ์ จริงๆ แล้วส่วนมากเท่าที่สังเกต พวกนี้มีประสบการณ์ทำ Client/Server กับ RDBMS มาหลายปี ก่อนหน้าที่เข้าสู่โลก OO นั้น เวลาไปรับงาน ก็สามารถจินตนาการออกเป็น Table ต่างๆ ได้ตั้งแต่เวลาคุยงานเลย พอมาถึงโลก OO ก็เอา Table นั่นเองเป็นฐานแล้วขยายภาพให้มันเป็น Class

ฟังดูแล้ว เหมือนกับมันไม่น่าจะเกี่ยวกันระหว่าง Table และ Class แต่ปรมาจารย์ Peter Coad บอกว่าที่พูดกันว่า OO เป็นการปฏิบัติวงการการเขียนโปรแกรมนั้น ไม่เห็นด้วยครับ เขาบอกว่า OO เป็นการขยายภาพของ Table นั่นเอง น่าเรียกว่าเป็นการปฏิรูปจึงจะถูก ในส่วนของ Table นั้นเรานิยาม Attributes (Fields ต่างๆ) ถ้าเปรียบกับสมัยนี้เขาบอกว่ามันยังไม่ครบถ้วน เป็นโลกแค่ครึ่งไป เมื่อบวกกับ Operations (Methods ต่างๆ) ตามด้วยความสัมพันธ์ มันก็ครบใบพอดี จึงไม่น่าแปลกใจเลยว่าทำไมกลุ่มคนเหล่านี้ถึงสามารถ กำหนดชื่อ class ได้โดยไม่ยาก

แต่ปัญหาที่พบมากสำหรับคนกลุ่มนี้ก็คือ Responsibility ครับ กำหนดชื่อ Class ได้ แต่พอไล่ลงไปในระดับ Field แล้วจะค่อนข้างมั่ว เพราะแนวคิดในการกำหนดตรงนี้มันมีความแตกต่างกันระหว่าง Relational และ OO ยิ่งกำหนด Operation แล้วละก็ยิ่งมั่วใหญ่ เพราะไม่คุ้นเคยเอาเสียเลย ทางแก้ก็คือให้ไปใช้วิธีอื่นดูสักพัก จนกระทั่งเราเข้าใจแนวคิด OO จริงๆ คราวนี้ค่อยกับมาใช้วิธีนี้ จะเห็นผลดีครับ

สิ่งที่คนกลุ่มนี้ต้องระวังอีกก็คือ การทำ Normalization คนที่เก่งๆ ในการทำ Relational นั้น มักจะออกแบบ Table ที่ถูกหลัก Normalization ระดับ 3 ได้เลย ไม่จำเป็นต้องปรับที่หลังอีก แต่ผลลัพธ์ที่ได้ มันก็ขัดกับ OO อยู่พอสมควร เรื่องนี้ต้องระวัง อีกเรื่องก็คือ เวลาเราออกแบบ Class นั้นเรารองรับความสัมพันธ์แบบ Many-to-Many แต่ Relational ไม่ใช่มันต้องแตกออกเป็น One-to-Many 2 ตัว คนกลุ่มนี้มักจะมองความความสัมพันธ์แบบ Many-to-Many ไม่ออกครับ

แล้วถ้านึกเป็น Class ไม่ได้มีอะไรพอช่วยได้ไหม

มีสิครับ ก็พวก Methodology ต่างๆ เขาก็มีสูตรสร้าง Class ด้วยกันทั้งนั้น ในบทความนี้ผมก็ยกตัวอย่างเอาที่รู้จักกันดีมาเล่าให้ฟัง แต่ก่อนที่จะพูดถึง ผมขอใช้เนื้อที่ตรงนี้อธิบายภาพรวมสักหน่อยก่อน เท่าที่จำได้ผมยังไม่เคยพูดเรื่องนี้มาก่อน

หลังจากยุค Waterfall แล้ว เราก็เข้าสู่ยุค Spiral มี Methodology อยู่หลายเจ้าเลยที่ถือกำเนิดขึ้นมา ตัวที่เราน่าจะได้ยินกันบ่อยๆ ก็จะมี Extreme Programming และ Unified Process ถ้าวางกันบนไม้บรรทัดแล้ว จะเห็นว่า XP นั้นจะทางซ้ายติดขอบ ส่วน Unified Process จะอยู่คนละขั้ว ขวาติดขอบเหมือนกัน ซ้ายขวาหมายถึงอะไร ทาง XP นั้นคนคิดก็คือกลุ่มโปรแกรมเมอร์ (แบบไม่เป็นทางการคือ Gang of Four และผองเพื่อน) ดังนั้นจึงเน้นถึงการเขียน Code เป็นหลัก เอกสารหรือ Diagram ต่างๆ ไม่เน้น เพราะยึดหลักว่าของที่เอาไปขายคือตัว Code ส่วน Unified Process เกิดมาจากนักคิดครับ และก็เป็นกลุ่มเดียวกันกับคนที่คิด UML (แบบเป็นทางการคือ Three Amigos) แนวคิดหลักของ Unified Process จะอยู่ที่ Project Management เน้นการสร้างเอกสาร และ ใช้ Diagram เป็นหลัก จะเห็นได้ว่ามันคนละขั้วเลย ทาง XP ก็มีคนไม่ชอบ เพราะอย่างแรกก็คือเรากำหนดเวลาตายตัวของโครงการได้ยาก เพราะใช้วิธี Onsite Customer ทำให้ผู้ใช้สามารถเรียกร้องเนื้องานเพิ่มได้เรื่อยๆ ส่วนทาง Unified Process นั้น ก็มีคนติว่า เสียเวลาและแรงงานในการทำเอกสารมากเกินไป (ถึงแม้ว่าจะบอกว่าบางตัวไม่ทำก็ได้) มีข้อดีข้อเสียครับ ใครที่รับงานเป็นทางการ ที่ต้องกำหนด Scope ให้ชัดเจนก่อนลงมือ เพื่อให้ประเมินราคาได้ แบบนี้ Unified Process ก็ดูเหมาะ แต่สำหรับงานแบบ Pioneer ที่ไม่เคยทำกันมาก่อน ยังไม่รู้ว่าต้องทำอะไร และทำได้อย่างไร กำหนดอะไรชัดเจนไม่ได้เลยในตอนแรก เวลาคิดเงินจึงต้องคิดเป็นราคาเหมา แบบนี้ XP ก็น่าจะเป็นทางเลือกที่ดีครับ

แต่โลกเราไม่จำเป็นต้องซ้ายสุดโต่งหรือขวาสุดขอบ มีคนหลายกลุ่มพยายามผสมผสานขั้วทั้งสอง เอาข้อดีของทั้งสองขั้ว และลดข้อเสียของขั้วทั้งสอง (หรือตรงกันข้าม เอาข้อแย่ของทั้งสองข้างมารวมกันไว้) ผลลัพธ์ที่ได้ก็จะอยู่ตรงที่ใดที่หนึ่งในบนไม้บรรทัด อยู่ระหว่าง Methodology ทั้งสอง มีหลายตัวมากเลยครับ เช่น Scrum, AM, DSDM เป็นอาทิ แต่ตัวที่ผมขอพูดเสริมให้เห็นภาพวันนี้คือ ICONIX ดังนั้นวันนี้เราจะมาดูกันว่า ทั้งสามนั้นเขามีแนวคิดการสร้าง Class แตกต่างกันอย่างไร

Extreme Programming

ทางค่ายของ Extreme Programming ไม่ได้มีอะไรใหม่ เขาใช้วิธีที่มีอยู่แล้วนั่นคือ CRC Card (Class Responsibility Collaborator Card) ว่าไปแล้ว XP ไม่เคยคิดอะไรใหม่เลย เพียงแค่เป็นตัวรวบรวมวิธีที่ดีที่เคยมีมาเอาเข้าไว้ด้วยกัน CRC Card ก็เช่นกันครับมีมานานแล้ว XP ยืมมาใช้เท่านั้น

CRC Card เป็นกระดาษ ถ้าได้กระดาษแข็งก็จะดี ขนาดเล็กกว่า Letter หรือ A4 เพราะไม่ต้องการให้ดูเป็นทางการจนเกินไป จะเป็น A5 ก็น่าจะดี หรือ 4"x6" ก็มีคนใช้ ซึ่งหน้าตาตามรูปนี้ครับ

print มาเยอะๆ ครับ 1 class ต่อ 1 ใบ คนอาจจะสงสัยว่าทำไมต้องตัดไม้ทำกระดาษ ในเมื่อเรามีเครื่องคอมพิวเตอร์แล้วทำไมไม่ใช้ ทำโปรแกรมมาสักตัวเพื่อรองรับการสร้าง CRC Card ก็สิ้นเรื่อง เขามีเหตุผลครับ หลักๆ เลยก็คือถ้าเป็นกระดาษนี้มันเข้าถึงได้สะดวกกว่าเยอะครับ ไม่จำเป็นต้องอยู่หน้าเครื่อง จะคุยกันที่ไหนก็ได้ แถมยังสามารถกระดาษติดแม่เหล็กไปติดบนกระดาน แล้วลากเส้นความสัมพันธ์เชื่อมได้เลย สะดวกกว่าในคอมพิวเตอร์ และให้เดานะครับ การใช้ลายมือจะทำให้รู้สีกเป็นกันเองครับ ไม่เครียดจนเกินไป

หลังจากที่เราได้กระดาษมาแล้ว เราต้องกำหนด class เพื่อเอามาใส่ หนึ่ง CRC card ต่อหนึ่ง Class แล้วเราจะเอาชื่อ class จากไหนมาใส่กันเล่า ทาง XP บอกว่าให้เราดู User Story หรือเอกสารประกอบ มองหาคำนามที่อยู่ในเอกสารเหล่านั้น ดูว่ามีอะไรบ้าง เอาคำนามนั่นแหละครับแปลงมาเป็นชื่อ class

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

จากนั้นเราก็มาดูครับ class แม่บ้านมันอยู่ลอยๆ เกินไป เราต้องสร้าง class ลูกจ้างขึ้นมา เพื่อให้ class แม่บ้าน Inherit เอาข้อมูลเหล่านี้ไปกรอกช่อง Superclasses และ Subclasses ให้เรียบร้อย อย่าลืมลบ "รู้ชื่อ" ออกาจาก class แม่บ้านนะครับ เอาไปใส่ไว้ใน class "ลูกจ้าง" แทน

จากนั้นให้เรานึกถึง Scenario คำว่า Scenario นั้นก็คือเหตุการณ์เหตุการณ์หนึ่งของโปรแกรมของเรา โดยปกติแล้วมีคนมาเป็นตัวเริ่มต้น Scenario ก็จะเป็นเรื่องราวตั้งแต่ต้นกระบวนการจนจบสิ้นนั่นเอง พอเรานึกถึง Scenario ขึ้นมา class ต่างๆ ก็เปรียบได้กับตัวละคร มันจะโลดแล่นเข้ามาในฉากนี้ และจุดนี้เอง คูณจะเห็นพฤติกรรมที่ class ต่างๆ จะกระทำซึ่งกันและกัน คุณเอาข้อมูลเหล่านั้น ไปกรอกลงช่อง Responsibilities ครับ จากนั้น ถ้า class หนึ่ง class ใดมีปฏิสัมพันธ์กับ class อื่น ก็ให้เราระบุ class ที่มันเกี่ยวข้อง ลงในช่อง collaborators เช่น class แม่บ้าน เกี่ยวข้องกับตลาด เพราะต้องไปจ่ายกับข้าว ก็ให้ใส่ "ตลาด" ลงในช่อง collaborators ครับ

มาถึงจุดนี้ เราก็เอา CRC card มาสร้างเป็น Class Diagram ผมคงไม่ต้องบอกมานะครับ ในส่วนของ Responsibilities จะถูกแปลงเป็น Attributes (พวกที่ขึ้นต้นว่า "รู้") และ Operations ส่วน Collaborators จะถูกแปลงให้เป็นเส้นความสัมพันธ์ต่างๆ ครับ ส่วน subclasses/superclasses ก็จะแปลงเป็น Inheritance นั่นเอง

ถ้าจะกล่าวให้มันถูกต้องเลยการทำ CRC card มันเป็นงานกลุ่มครับ ซึ่งทาง XP ก็มีการกล่าวถึงระเบียบวิธีการอยู่ไม่น้อย ผมขอตัดออก เน้นเอาเฉพาะขั้นตอนที่ให้เห็นภาพเท่านั้น ถ้าใครสนใจลองไปหาหนังสือ XP เพิ่มเติมครับ มีเยอะ ผมไม่แนะนำดีกว่า ผมว่าผมแนะนำเล่มนี้กว่า รายละเอียดแบบกระจ่างในการกำหนด Responsibilities และ Collaborators ถ้าใครสนใจก็ลองไปหาซื้อดูครับ

Unified Process

แนวคิด Unified Process ในการสร้าง Class นั้น ผมว่าส่วนหนึ่งก็คงได้รับอิทธิพลมาจาก CRC Card เหมือนกัน แก่นคล้ายกัน แต่วิธีการนั้นแตกต่างกันอย่างเห็นได้ชัด เรามาดูรายละเอียดของ Unified Process กัน

ขั้นตอนแรกในการวิเคราะห์งานนั้น Unified Process กำหนดให้สร้าง Use Case (Use Case ก็เป็นของเก่าครับ เกิดก่อน Unified Process นานเลยครับ)Use Case เป็นการบรรยายถึงกิจกรรมในจินตนาการครับ จินตนาการว่าถ้า software เราเสร็จ มันจะมีกิจกรรมอะไร แล้วมีใครเกี่ยวข้องบ้าง อาจจะกล่าวได้ว่า มันจะอธิบายว่าใครทำอะไร ที่ไหนเมื่อไร แต่ไม่ได้บอกว่าทำอย่างไร (เหมือนกับ Scenario ใน CRC Card) ในกิจกรรมหนึ่งก็ต่อ Use Case ตัวหนึ่ง ที่ยกตัวอย่างกันบ่อยๆ จนกลายเป็นมาตรฐานสำหรับ Use Case ไปแล้ว นั่นก็คือกิจกรรมเกี่ยวกับการทำธุรกรรมกับตู้ ATM เราก็จะมี Use-Case สำหรับการถอน การฝาก การถามยอด แยกกันครับ

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

เมื่อเราได้ Use Case มาแล้ว ขั้นต่อไปก็เหมือนกับ CRC Card ครับ คือให้มองหาคำนามใน Use Case นั้น เมื่อเราได้คำนามมาแล้ว เราก็เอาคำนามที่ได้มาเข้าสู่กระบวนการปรับบทบาทครับ เช่นถ้าได้คำนามว่า Employee มันก็ดูกว้างไป ระบุให้ชัดกว่านี้ครับว่าเป็น Accountant เป็นต้น เมื่อปรับเรียบร้อยแล้ว เราก็วาด Class Diagram เป็นก้อนๆ เอาไว้ หรือเอาคำนามไปใส่ไว้ในกล่องสี่เหลี่ยมของ Class Diagram นั่นเอง ตรงนี้จะใช้ UML Class Diagram tool วาดเอา หรือจะวาดในกระดาษหรือบนกระดานก็ไม่ผิดกติกาแต่อย่างใด

เมื่อได้ ก้อน Class ต่างๆ แล้ว ลองลากความสัมพันธ์ดูครับ ใช้ Association อย่างเดียวก็พอ แต่สิ่งที่ควรจะใส่ก็คือข้างไหน เป็น one ข้างไหนเป็น Many พร้อมทั้งตั้งชื่อบทบาทที่เส้นด้วย จะได้อ่านเข้าใจง่าย

จากนั้นเราก็ลองเอา Attributes ใส่ตาม class ต่างๆ ยังไม่ต้องเน้นความถูกต้องมากครับ เพราะเรามีเครื่องมืออีกตัวหนึ่งที่ช่วยให้กำหนดสิ่งต่างๆ ได้ถูกต้องขึ้น นั่นก็คือ Sequence Diagram ว่ากันไปแล้วขั้นตอนนี้ก็เหมือนกับ CRC Card ที่ไล่ตาม Scenario แต่ต่างกันตรงที่ว่า Unified Process จะเห็นภาพได้ชั้ดเจนกว่า เพราะวาดเป็น Sequence Diagram (ทุกคนคงรู้จัก Sequence Diagram กันนะครับ) ระหว่างที่วาดนั้น Attributes และ Operation ต่างๆ ก็จะผุดขึ้นมา คุณก็เอาไปปรับปรุงใน Class Diagram ได้เลย

ขั้นตอนสุดท้ายคุณก็ปรับ Class Diagram ที่ได้ให้ถูกต้องกระชับขึ้น Class อาจจะถูกยุบ หรืออาจจะกลายเป็นเพียง Attributes หรือมี Class ใหม่ๆ เกิดขึ้นมา ก็ไม่ต้องแปลกใจนะครับ เป็นเหตุการณ์ปกติ เมื่อเสร็จแล้ว เราก็จะได้เอกสาร 3 ฉบับ นั่นคือ Use Case (+Diagram) Class Diagram และ Sequence Diagram เพื่อส่งงานต่อให้โปรแกรมเมอร์เอาไปทำงานได้เลยครับ

ผมเล่าแบบตัดตอนมากนะครับ เพราะใน Unified Process นั้นมีรายละเอียดมาก ตัวช่วยก็มีเยอะ ถ้าสนใจรายละเอียดแบบทุกกระบวนการ ผมแนะนำ หนังสือเล่มนี้ครับ

ICONIX

อย่างที่ผมบอกตั้งแต่แรกครับ XP อยู่ข้างหนึ่ง UP อยู่อีกข้าง แล้วมี Methodology กระจายตัวกันอยู่บนไม้บรรทัด แต่ ICONIX พิเศษหน่อย มีคนไม่น้อยเชื่อว่ามันอยู่ตรงกลางพอดี (หกนิ้ว) เป็นภาษาพุทธก็เรียกว่าเป็นยมบาล ทำกรรมดีและชั่วเท่าๆ กัน (ไม่ได้บอกว่าข้างไหนดีหรือชั่วนะครับ)

ถ้าถามผมว่าผมชอบวิธีไหน ผมชอบของ ICONIX ตัวนี้นี่เอง แต่อย่ามาเอาตามผมนะครับ มันถูกจริตของผม แต่อาจจะไม่ตรงกับของคุณก็ได้ แต่อย่างไรเสีย ทดลองทุกวิธีแล้วค่อยสรุปจะดีกว่า

ที่บอกว่ามันถูกจริตผม เพราะว่า ผมอยู่ในกลุ่ม Relational ที่กล่าวมาข้างต้นครับ เวลาคุยๆ นี่นึกเป็น Table ได้ทันที ผมเองก็ไม่ชอบรำมวยแบบ Unified Process ก็ชื่อ Class มันอยู่ในหัวของผมเกือบหมดแล้ว ICONIX ก็ดีใจหาย บอกว่าขั้นตอนแรกก็นิยาม Class กันได้เลย

ว่าแล้วผมก็เริ่มบรรเลงการสร้าง Class เลย แต่ก็เช่นเดิมครับ ค่อนข้างจะคร่าวๆ ไม่เน้นรายละเอียดพวก Attributes และ Operations สักเท่าไร ทำให้มีพอมีอะไรที่จับต้องได้ก็พอครับ เมื่อสร้างเสร็จแล้ว ICONIX ก็บอกให้ผมสร้าง Use Case แบบเดียวกันกับใน Unified Process คิดกันคนละแบบเลยเห็นไหมครับ Unified Process สร้าง Use Case เพื่อกลั่นกรองให้ได้ Class แต่ ICONIX กลับสร้าง Class Diagram ก่อนแล้วค่อยสร้าง Use Case รายละเอียดการสร้าง Use Case ผมคงไม่ฉายซ้ำนะครับลองอ่านดูจากข้างบนครับ

เมื่อได้ Use Case แล้วเอา Use Case ที่ได้นั้นมาขยายเพิ่มเติมโดยใช้ Robustness Diagram เชื่อว่ามีหลายคนคงไม่เคยได้ยินชื่อ Robustness Diagram จริงๆ แล้ว Robustness Diagram คนคิดค้นไม่ใช่อื่นไกลครับ เป็นคนหนึ่งในกลุ่ม Three Amigos ที่ชื่อว่า Ivar Jacobson นั่นเอง ก่อนที่จะมารวมกลุ่ม Three Amigos ซึ่งถือว่าเป็นเสาหลักเสาหนึ่งของยุทธภพ Jacobson เคยเป็นเจ้าสำนัก Objectory มาก่อน และ Diagram ตัวหนึ่งที่เขาคิดค้นขึ้นมานั้น ก็คือ Robustness Diagram แต่พอมารวมตัวเป็นสำนัก Rational เจ้า Robustness Diagram ก็ถูกโยนทิ้งไป ไม่ปรากฏใน UML ICONIX นี่ไปปลุกผี Robustness Diagram ให้ฟื้นคืนชีพอีกครั้ง ลองมาดูหน้าตา Robustness Diagram กันครับ

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

เรามาลองดูครับ Robustness Diagram จะประกอบด้วย รูป 3 แบบ นั่นก็คือ Boundary รูปที่คนชี้หานั่นแหละครับ คือรูปที่มีกำแพงยื่นออกไปทางด้านซ้ายนั่นเอง Boundary เป็นตัวบอกว่า หน่วยนี้เป็นหน่วยที่ติดต่อกับผู้ใช้ ยังมีแบบที่สองครับ ที่เป็นวงกลม แล้วมีขีดเส้นใต้ข้างล่าง เราเรียกพวกนี้ว่า Entity ถ้าว่ากันในเรื่อง Class แล้ว มันก็พวก Persistence Class นั่นเอง ส่วน วงกลมที่มีเครื่องหมายน้อยกว่าอยู่บนหัว จริงๆ แล้วแสดงการหมุนครับ พวกนี้เรียกว่า Controller เป็นตัวประสานงานอยู่ตรงกลางระหว่าง Boundary กับ Entity ครับ ใครรู้จัก Pattern เยอะๆ ก็จะร้อง ไอ้หย่า นี่มัน Model-View-Controller นี่นา ใช่แล้วครับ ไม่ผิดหรือ Model-View-Controller นั่นเอง การแยกหมวดหมู่เช่นนี้ทำให้เรามองเห็น Class ได้ชัดขึ้นมากครับ

คำถามตามมาครับ แล้วเราจะรู้ได้อย่างไรว่าควรมีวงกลมอะไรบ้าง ข้อนี้ตอบไม่ยากครับ ก็เอา class ที่สร้างมาได้ตั้งแต่ต้นมาเป็นตัวตั้งสิครับ ถ้าขาดไปบางตัว มาถึงขึ้นนี้ก็สามารถเพิ่มเติมได้ แต่สังเกตนะครับ เราไม่ได้สนใจ Attributes และ Operations เลย

มาอีกคำถามหนึ่งที่น่าสนใจ ก็ Robustness Diagram มันไม่มีใน UML แบบนี้มิต้องวาดมือกันหรือ ไม่ขนาดนั้นครับ จริงๆ แล้วสาเหตุหลักที่ Three Amigos ตัด Robustness Diagram ออกไป ไม่ใช่เพราะมันไม่ดีนะครับ แต่หาก เราสามารถทดแทนมันได้ด้วย Class Diagram ครับ ใน Class Diagram เขาจะมีสิ่งหนึ่งที่เรียกว่า Stereotype ปกติแล้วก็มี 3 อย่างนี้ให้เลือก ลองดูตัวอย่างจาก Visio ครับ

Visio ไม่ได้รองรับ Robustness Diagram ผมเลยต้องไปที่ Menu UML->Stereotypes เพื่อเพิ่มคำทั้งสาม ที่ Base Class เป็น Class แต่ถ้าเป็น Magic Draw พอผมเลย Stereotypes มันก็มีทั้งสามแบบให้เลือก พอเลือกแล้ว มันเปลี่ยนรูปจากกล่องสี่เหลี่ยมให้กลายเป็นอย่างนี้ครับ

เมื่อเราได้ Robustness Diagram แล้ว คราวนี้ก็เหมือนกับ Unified Process แล้วครับ คือสร้าง Sequence Diagram ซึ่งน่าจะสร้างได้ง่ายขึ้นมาก เพราะเราดึงเอาวัตถุดิบจาก Robustness Diagram ไปใช้นั่นเอง

เมื่อได้ Sequence Diagram แล้วก็ไม่แตกต่างจาก Unified Process ครับ คือเอา Attributes, Operations และความสัมพันธ์กลับไปปรับปรุง Class Diagram ที่เราสร้างขึ้นไว้ตอนแรก ก็เป็นอันเสร็จพิธี

ถ้าอยากได้ข้อมูลเพิ่มเติมลองหนังสือเล่มนี้ครับ

ตัวช่วย

ถ้าถามผมว่าวิธีใดข้างต้นให้ผลลัพธ์ที่ดีกว่ากัน ผมคงตอบไม่ได้ แต่สิ่งหนึ่งที่ตอบได้เลยก็คือ ไม่มีวิธีไหนที่สมบูรณ์ 100% ไม่ว่าจะผ่านกระบวนการใดก็ตาม สุดท้ายเวลาเขียนโปรแกรมไป ก็ต้องมีการปรับแก้อยู่ดี ให้เรายอมรับสัจจธรรมในข้อนี้ครับ แต่มือใหม่ไม่ต้องกังวลใจครับ เรามีตัวช่วย (มือเก่าก็ใช้ได้เช่นกัน) อยู่ 3 ตัว ดังนี้ครับ

ตัวช่วยกำหนดชื่อ class

มีตัวช่วยตัวหนึ่งที่เรียกว่า Conceptual Class Category List เป็นรายการหมวดหมู่ของของต่างๆ รายการหมวดหมู่มีดังนี้ครับ

• สถานที่
• Transaction ที่ต้องเก็บ
• บทบาทของคน
• Container ของ ข้อมูล
• สิ่งที่อยู่ใน Container
• สิ่งที่จับต้องได้
• ระบบคอมพิวเตอร์ภายนอก
• คำนาม
• องค์กร
• เหตุการณ์
• กระบวนการ
• กฏ ข้อจำกัด นโยบาย
• catalog
• งาน สัญญา
• การเงิน บริการ
• คู่มือ หนังสือ

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

ตัวช่วยกำหนด Attributes และ Operations

เมื่อเราได้ชื่อ Class แล้ว เนื้อหาที่อยู่ใน Class นั้นยังคงเป็นปัญหาอยู่ จะลองผิดลองถูก ก็กลัวเสียเวลาเยอะ ไม่เป็นไรครับ เรามีตัวช่วยอีกแล้ว ใน Methodology ที่ชื่อว่า MDA (Model Driven Architecture) ของ OMG นั้นมีการคิดค้นสิ่งหนึ่งที่เรียกว่า Archetype ขึ้นมา ถ้าแปลเป็นภาษาที่เราชาวคอมพิวเตอร์เข้าใจนั่นก็คือ Pattern นั่นเอง แต่ไม่ใช่แบบ Design Pattern นะครับ มันเป็น Pattern งานธุรกิจ มีเนื้อหาและความสัมพันธ์ที่ตรงกับงานเลย เช่น Pattern ของ สินค้า เป็น class ที่ design เสร็จเป็นของสำเร็จรูป มีการทำ category การจัดการ package นโยบายราคาเป็นต้น สมมุติว่าเวลาคุณออกแบบ แล้วเกิดมีคำว่าสินค้าโผล่ขึ้นมา คุณสามารถยืม Archetype เอามาใส่ได้เลยครับ มี Attributes Operations และความสัมพันธ์ให้เสร็จสรรพ พอเอามาก็เอามาปรับปรุงตัดของที่ไม่ต้องการออก เพิ่มส่วนที่ไม่มีใน Archetype เข้าไป ผมว่ามันดีกว่าการเริ่มต้นที่ 0 เลยเป็นไหนๆ ถ้าเปรียบเทียบกับ Design Pattern แล้ว ผมเห็นประโยชน์ของ Archetype มากกว่าเยอะ (ถ้าอยากได้เหตุผล ก็ลอง Vote บทความ Design Pattern ผมจะร่ายยาวให้อ่านกัน)

ตัวช่วยกำหนดความสัมพันธ์ของ Class

หนังสือ Analysis Patterns ของ Martin Folwer เจ้าเก่า หนังสือเล่มนี้ ก็เป็น Pattern เหมือนกันคล้ายกับ Archetype แต่ไม่เน้น Attributes หรือ Operations แต่หากเน้น Process มีกลยุทธ์เยอะเลยครับ เห็นจากตัวอย่างๆ จริงๆ กันเลย ใครสนใจเรื่องทำบัญชี มี Pattern ตรงๆ ให้ศึกษา ถ้าได้แนวคิดแล้วก็สามารถประยุกต์ใช้กับงานอื่นได้อีกต่างหาก แต่ข้อเสียก็มีครับ หนังสือเล่มนี้ไม่ได้ใช้ UML เลยอ่านยากหน่อย ผนวกกับไม่ได้เน้น Attributes กับ Operations จึงทำให้มีแต่คำอธิบาย ไม่ค่อยมีตัวอย่าง นับว่าเป็นหนังสืออ่านยากเล่มหนึ่งครับ พยายามกันหน่อยครับ

ก่อนจบขอนอกเรื่องไปยัง UML

มีคนพูดถึง UML กันมาก วันนี้ผมขอนอกเรื่องใช้พื้นที่ตรงนี้อธิบายให้เห็นภาพกันหน่อย UML นั้นที่จริงแล้วเป็น Diagrams ที่ชนะการประกวดมา ด้วยเหตุว่า ในยุคอดีตนั้น มีสำนัก OO อยู่หลายสำนัก แต่ละสำนักก็พูดเรื่องที่ไม่หนีกันเท่าไรหรอกครับ แต่กลับมี Diagram อยู่มากมายเข้าทำนองต่างคนต่างคิด ดังนั้นเพื่อให้ไม่สับสน จะใช้กำลังยุบสำนักก็ใช่ที่ เลยมีกลยุทธ์ ยิงนัดเดียวได้นกสองตัว คือประกาศกันทั่วว่า เราจะมีมาตรฐานกลางของ Diagram ที่จะใช้ร่วมกันทุกสำนัก เชิญทุกคนเข้ามาประกวด เหตุการณ์ก็สนุกครับ สำนักเล็กๆ ก็รวมตัวกันเป็นก๊ก เพื่อมีอำนาจต่อรองกัน ดีครับ มันเลยเหลือไม่กี่สำนักในยุคปัจจุบัน และสุดท้ายเราก็ได้ UML ตอนปี 1997

แต่สิ่งที่ผมอยากจะอธิบายคือ UML นั้นไม่ผูกติดกับ Methodology ไม่มีสูตรตายตัวว่าการออกแบบต้องเริ่มจาก Diagram A แล้วค่อยต่อ B เป็นต้น ทั้งนี้ขึ้นอยู่กับปรมาจารย์แต่ละสำนักจะนิยาม (คุณจะเห็นได้จาก Methodology สามตัวที่ผมแสดงให้ดู มันไปกันคนละทางเลย) คุณอาจจะใช้ลอยๆ ก็ได้ แต่ถ้าใครมาบอกคุณว่าออกแบบโปรแกรมโดยใช้ UML คุณต้องถามก่อนว่าเขาใช้ Methodology สำนักไหน หรือแต่งเอง หรือตีลังกาคำพูดอีกแนวหนึ่งว่า UML มันเป็นเพียง Diagram ถ้าจะใช้มันในโครงการ ก็ต้องเลือกใช้ Methodology

ผมไม่อยากให้เราเสียเวลาเรียน UML ระดับลึกมากนัก เพราะที่มันมีรายละเอียดมาก มันทำไปเพื่อรองรับ Methodology ต่างๆ ให้ได้มากที่สุด ผมว่าคุณควรจะเริ่มต้นที่ Methodology และใครเรียกใช้ UML ระดับใด ก็ให้ใช้แค่ระดับนั้น มิฉะนั้นเสียเวลาเปล่าๆ

Supoj

26/Jul/05

ที่มา: http://www.twoguru.com/playground/article/classdef.htm

ลิงค์น่าสนใจ : http://search.appjob.com/search.php?kw=class%20diagram

เรียนชดเชย Bus Req. และตอกย้ำ Assignment

สุขสันต์วันพ่อ แต่คิดว่าเพื่อน ๆ หลาย ๆ คนคงอยู่ที่หน้าจอ เพราะนั่งทำ Assignment หัวปั่นกันอยู่ สู้ต่อไปครับ ... ข่าวแจ้งประชาสัมพันธ์เป็นการตอกย้ำกันอีกทีสำหรับสัปดาห์นี้ ที่ต้องมีเรียนชดเชย Business Software Requirement Analysis ของ อ.สมจารี จำนวน 3 ครั้ง ดังนี้

วันศุกร์ที่ 7 ธันวาคม
เวลา 18.00 น. ห้อง IT Studio

วันอาทิตย์ที่ 9
ธันวาคม
เวลา 9.00 น. - 16.00 น. ห้อง 208 (อาคารไชยศสมบัติ 3)

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

Advanced DBMS / อ.วัช
6 ธันวาคม
-No.2: DB Reverse Engineering
27 ธันวาคม
-No.3: DB Design Project

OO-TECH / อ.อัษ
11 ธันวาคม
-No.2-3: Interaction Diagram (Sequence Diagram)
18 ธันวาคม
-No.2-4: State Diagram

BUS SW REQ / อ.สม
7 ธันวาคม
-No.2: Org. Chart กับ Context Diagram (Business Model)

BUS INFO /อ.ถาวร
ยังไม่กำหนดส่ง
No.1 Inventory System (งานเดี่ยว)


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

ช่วงนี้ก็ใกล้สอบแล้ว ดูแลกันดี ๆ ในกลุ่มนะครับ ช่วยกันเรียน ช่วยกันทำงาน ช่วยกันติว ใครคิดว่าเข้าใจเรื่องไหน ก็แจ้งได้นะครับ แล้วจะได้นัดติวหนังสือกัน รักษาสุขภาพด้วย...

OO Concept ข้างตำรา

คลาสเมื่อวาน 27 พ.ย. 50 บรรยายเป็นครั้งที่ 4 เรื่อง Interaction Diagram (Sequence & Comunication Digaram) ทำให้นึกย้อนกลับไปถึงบรรยายครั้งที่ผ่าน ๆ มา เริ่มจากครั้งที่ 1 เป็นการแนะนำนำให้รู้จักคุณสมบัติของแนวคิด (กระบวนการคิด) ของ Object-Oriented อะไรคือ Class อะไรคือ Instance มันนิยามต่างกันอย่างไร แต่ที่แน่ ๆ คือ Object จะมีคุณสมบัติอยู่ 3 ข้อใหญ่ ๆ

1.Encapsulation คือ ทำงานได้เบ็ดเสร็จ คือ พูดง่ายลองนึกถึงตัวเรา มีข้อมูล (Attribute) และ เราก็รู้จักจัดการกับข้อมูลของเราด้วยวิธีการ (Method) ของเรา คนอื่นแค่บอกมาว่า อยากได้อะไร หรือ ต้องรู้ว่าเราทำอะไรให้ได้บ้าง สรุปคือ แค่บอกมา (ส่ง message มาตาม public channel) เดี๋ยวจัดให้ (เรื่องของ I You ไม่เกี่ยว จัดการอย่างไร ขอเป็น Private นะ) เห็นม๊ะ แสดงว่ามันต้องมีคนอื่น (Class อื่นๆ) ต้องรู้จักเราด้วย เพราะจะมาใช้ หรือมารู้จักนี่หละ มันก็เกิดเป็นความสัมพันธ์ (Relationship) ไง พอมันสัมพันธ์กันเยอะ เริ่มกิ๊กกันเยอะ ก็ต้องไปเขียน Class Diagram จะได้รู้ว่ากิ๊กไหน รู้จักกันบ้าง ทางไหน อย่างไร จะได้ไม่งง อ้าวก่อนจะออกนอกเรื่อง (นอกแคปซูล) ...ไปไกล ขอหยุดก่อนนะ

Generalization Abstraction

(Superclass-Class-Subclass)

2. Inheritance คือ กรรมพันธุ์ ทั้งที่เป็น Physical เช่น อะไรที่ common มันก็จะสืบทอดมาด้วย (ก็พวก Attibute ที่มันมีเหมือนกันไง) รวมถึง Logical อันนี้ดูที่นิสัย (Method) หรือเรียกง่ายๆ ว่า สืบทั้งคุณลักษณะ และสันดานแล้วกันครับ คือ เหมือนเรานี่หละครับ เอกเทศ เป็นตัวเราเอง ที่เรียกว่า Encapsulation แล้วยังไม่พอ เขาพยายามจะบอกว่า บางทีเราก็มี ลักษณะรูปร่าง และสันดาน ที่เป็นกรรมพันธุ์ ที่ยัดเยียดมาให้ ติดมาจาก พ่อ และแม่ของเรา งงหละซิ ... เช่น พ่อ แม่ เป็น นก นกมีลักษณะนิยาม คือ มีปีก 2 ข้าง มีขา 2 ขา มีหางด้วยนะ ส่งเสียงร้องได้ และบินได้ ลูกนก ออกมาอาจจะ สีดำ สีขาว หางยาว หางสั้น หางกุด ร้องเพราะ ร้องไม่เพราะ ไอ้ ดำ ๆ ขาว ๆ ยาวๆ สั้น ๆ เพราะ ไม่เพราะ ที่บอกมามันคือ Value นะ แต่มันก็คือ ลักษณะ (Attributes) เดียวกันเหมือน พ่อ และแม่ของมัน ใช่ไหม จะนกเอี้ยง นกอีเห็น นกกระจอก (Instance) จะแบ่งไปสักกี่ร้อยสายพันธุ์ มันก็ มีปีก 2 ข้าง มีขา 2 ขา มีหางด้วยนะ ส่งเสียงร้องได้ และบินได้ เราเรียกรวมไม่รู้หละไอ้แบบนี้ นก หมด (Class นก) จะเป็นหมาได้อย่างไร
เหมารวม เรียกลักษณะเหมารวมที่นิยาม ๆ ว่า Class ไง

อันนี้มันแล้วแต่นิยามของ คลาส ถ้าบอกว่า สิ่งที่บินได้ (มีปีกสองข้าง ลอยตัวในอากาศได้) ก็อาจจะแยกเป็น สิ่งมีชีวิตที่บินได้ กับ สิ่งไม่มีชีวิตที่บินได้ เห็นม๊ะ เห็นม๊ะ แค่นึกยังนึกว่า บินได้ บินได้ แสดงว่า มันก็สืบสันดานของที่บินได้มา นก ก็จะกลายเป็นคลาสลูก (Sub Class) ของสิ่งที่บินได้ที่มีชีวิต ทันที เครื่องบิน ก็จะกลายเป็น Sub Class ของสิ่งไม่มีชีวิตที่บินได้ แต่มันบินได้เห็นปะ ... การคิดแบบนี้มันทำให้เกิดการ Reuse หรือ ทำให้ไม่ต้องคิดอะไรซ้ำ ๆ ก็ใช้สิ่งที่มีอยู่แล้วให้เกิดประโยชน์

3. Polymorphism เขายังมองลึกซึ้งต่อไปว่า คนเราอะนะ หรือลูก ๆ ที่พ่อแม่เดียวกันนี่หละ สืบสันดานมาจากพ่อแม่ก็จริงอยู่ แสดงพฤติกรรม (Behavior หรือ Method) ได้เหมือนกันก็จริงอยู่ แต่ลองไปดูกระบวนการ (Process) ดิ มันต่างกัน เช่น สิ่งที่บินได้แบบมีชีวิต เวลาบิน (Method บิน) มัน กางปีกสองข้างขยับขึ้น ขยับลง = บิน แต่ ถ้าแบบไม่มีชีวิต เวลาบิน มันกางปีกก่อน แล้ววิ่งไปข้างหน้า เชิดหัวขึ้น = บิน เห็นม๊ะ เห็นม๊ะ บินได้ แต่ว่าขอแอบต่างนิดส์นึง ถ้าเครื่องบินปีกขยับขึ้น ขยับลง เอออันนี้ไม่ต้องคิดอะไร ท่องนะโม 3 จบ ลุ้นกันอีกทีตอนถึงพื้น

จากข้อ 1 สรุปว่า มองตัวเรา ข้อ 2 และ 3 สรุปว่ามองที่ครอบครัวของเรา

พอเรามองแบบนี้ปุ๊ป เอาข้อ 1 ก่อน อยู่คนเดียวได้เหรอ? ถ้าเป็นสิ่งเดียวที่ไม่ต้องยุ่งกะใคร คำตอบคือ แล้วจะไปสนใจมันทำไมให้ปวดหัวคร๊าบบพี่น้อง .. ไอ้เพราะว่าอยู่โดด ๆ ไม่ได้นี่หละครับ มันเลยทำให้เรามีวิชาชีพทำมาหากินทุกวันนี่หละ เอ้ามาดูกัน อยู่คนเดียวไม่ได้ ก็ต้องไปมีความสัมพันธ์ กับ คนอื่น จริงม๊ะ (Relationship ระหว่าง Class เรียกหรู ๆ ว่า Association) ตามธรรมเนียมลากเส้นไปเชื่อมกันซะ แล้วก็บอกว่า สัมพันธภาพระหว่างเรา นะแบบไหน จะมาหลายทีไม่จำกัด (*) หรือว่ามาทีเดียว (1) หรือว่ามาได้จำกัดจำนวนครั้งไม่เกิน 30 ครั้งตามใจ (0..30) หรือไม่รับปากว่าจะมา แต่ถ้ามาขออนุญาตมาหลาย ๆ ที (0..*) ยังไงก็มาแน่ ๆ ที่รัก แล้วจะมาอีกหลาย ๆ ที (1..*) ก็ว่ากันไป เราเรียกการเขียนพวกนี้ว่า Carinality หรือ Multiplicity อ่อ จะใช้ n แทน * ก็ได้ไม่ผิด


มาข้อ 2 ข้อ 3 ความสัมพันธ์กันแบบ ครอบครัวของเรา ของกันและกัน ยกทีมมา อุตส่าห์ทำตัวเทา ๆ ไว้ก่อน ที่เป็น Generalization ก็จะเป็นความสัมพันธ์จากนิยามคุณสมบัติของ Object ในข้อ Inheritance และ Polymorphism ไง ความเป็นเครือญาติ เหล่า ก๊ก กอ แก๊งค์ พวกเดียวกันนี่หละ มันก็จะมีความสัมพันธ์กันแบบใกล้ชิดสนิทแนบ เราเรียกมันว่า Composite หรือ Aggregation ซึ่งจะเกิดจากความสัมพ้นธ์ที่เป็นส่วนหนึ่งของกันและกัน ฉันขาดเธอมิได้ ประมาณนี้ ภาษาอังกฤษเรียกว่า "is-part-of" "is-kind-of" ต้องมาประกอบเข้าด้วยกัน เวลาเขียนเส้นความสัมพันธ์ ก็บอกให้รู้ด้วยสัญลักษณ์ สี่เหลี่ยมข้าวหลามตัดไว้ตรงหัว ถ้าแบบเหนียวแน่นมาก ๆ ก็ทำทึบ ๆ (Composite) ถ้าแบบธรรมดาก็ไม่ต้องไประบายทึบ (Aggregation) ส่วนใหญ่หัวเหลี่ยมจะไปแปะไว้กับคลาสหลัก นึกถึงดอกกุหลาบ มีก้าน มีดอก ดอกคือเหลี่ยม ๆ นั่นหละครับ เวลาที่ยื่นดอกกุหลาบให้แฟน แล้วบอกว่า ขอเป็นส่วนหนึ่งของชีวิตคุณ คงไม่เอาก้านดอกกุหลาบ ชี้ไปที่แฟนหรอกนะครับ เหอๆๆ


จำไว้อย่างว่า "เมื่อ instance ไหน เป็น Subclass ของ Class ใดแล้ว ก็ต้องจงรักภักดี กับหัวหน้า Super Class นั้นตลอดไป ห้ามกระโดดไปมา" ... เช่น นก ถึงจะบินได้ ก็ห้ามไปสังกัด สิ่งไม่มีชีวิตที่บินได้ มันเย้ยหยัน เสียมารยาท เสียการปกครอง

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

Object

ฉันก็มีชีวิตเลือดเนื้อ (Attribute) จิตใจ (Method) และความสัมพันธ์ (Association)

เว็บบอร์ด BSD2EX มาแว้ว ...

หลังจากที่เสียงหัวเราะ อย่างครึกครื้นได้กลับคืนมายัง BSD2EX ในวันลอยกระทง (24 พ.ย.) และได้คัดเลือกนางนพมาศ ประจำปี 50 น้องกิ๊ป รองน้องญิ๋ง และขวัญใจช่างภาพน้องเจิน จากผลการโหวตกันไปเป็นที่เรียบร้อยแล้ว คนที่ไม่ได้รับตำแหน่งไม่ต้องเสียใจ เพราะความสวย มีพอๆ กัน แต่ความ ซว... ที่เพื่อน ๆ ในห้องมอบให้มีไม่เท่ากัน ฮา ...

เข้าเรื่องกันครับ มีหนุ่มสุดหล่อใจดี ไม่ประสงค์ออกนาม นาย ก. นามสมมติ กลุ่ม 3 ได้มาคุยกะเฮีย แล้ว offer ว่าที่กลุ่ม ได้ทดลองเปิด web board ไว้คุยงานกัน แล้วเห็นว่าน่าจะมีประโยชน์กับเพื่อน ๆ ในรุ่น เรื่องดี ๆ บอกเฮียมา ก็จัดส่งมอบต่อให้รุ่นครับ อ่อ ... ไปหาและขอบคุณกันเองหละกันคร๊าบ คงไม่ยากเกินกว่า Assignment หรอกนะครับ

สุดหล่อเขาแบ่ง เว็บบอร์ดแบ่งไว้ให้ตามกลุ่ม 6 กลุ่มนะครับ แต่ว่า สามารถแสดงความคิดเห็นได้ทุกกระทู้ ทั้งนี้เพื่อความสะดวกในการนัดแนะ แต่ว่าเราไปแสดงความคิดเห็นที่กลุ่มไหนก็ได้

แล้วจะล็อกอินยังไง?
ก็จัดการสร้าง Username และ password ให้ทุกคนแล้ว โดย username เป็น รหัสนิสิต ส่วนรหัสผ่าน เป็นวันเกิด และเดือนเกิด (ddmm) 4 ตัว (ไม่มีปี คงเข้าใจนะ...) การล็อกอินต้องเลือกกลุ่มให้ถูกต้องด้วยนะครับ ตย. รหัสนิสิต 508-12345-26 อยู่กลุ่ม 6 เกิดวันที่ 6 เดือน กันยายน ใส่ข้อมูลตามนี้

Username: 5081234526
Group: 6
Password: 0609

หมายเหตุ

Group1 กลุ่มเบิร์ด, Group 2 กลุ่มท่านก็อป, Group3 กลุ่มศักดิ์, Group4 กลุ่มตัน, Group5 กลุ่มเม้ง, Group6 กลุ่มเฮีย

ถ้ามีปัญหารหัสนิสิตผิด แจ้งมาที่เฮียครับ แต่ถ้าจำวันเกิดไม่ได้ เอ่อ... อันนี้...ดูที่บัตรประชาชน หรือสำเนาทะเบียนบ้านครับ

แล้วต้องไปที่เว็บไหน?

นี่เลย .... http://www.bsd2ex.com/2007/board หรือ ดูจากใน Blog ตรงส่วน Web Board คร๊าบ

ชื่นใจจริง ๆ เฟ้ย ...จบข่าว

จุฬาฯ ติดอันดับ 37 ม.ดีของเอเซีย 527 ม.ดีของโลก

CONTINENT RANK	UNIVERSITY	COUNTRY	WORLD RANK
1	UNIVERSITY OF TOKYO		59
2	NATIONAL TAIWAN UNIVERSITY		96
3	KYOTO UNIVERSITY		116
4	BEIJING UNIVERSITY		120
5	KEIO UNIVERSITY		139
6	NATIONAL UNIVERSITY OF SINGAPORE		158
7	UNIVERSITY OF HONG KONG		190
8	CHINESE UNIVERSITY OF HONG KONG		198
9	NATIONAL CHIAO TUNG UNIVERSITY		208
10	NAGOYA UNIVERSITY		235
11	KOREA ADVANCED INSTITUTE OF SCIENCE & TECHNOLOGY		260
12	OSAKA UNIVERSITY		266
13	TSINGHUA UNIVERSITY CHINA		270
14	TOKYO INSTITUTE OF TECHNOLOGY		275
15	TOHOKU UNIVERSITY		305
16	UNIVERSITY OF TSUKUBA		306
17	SEOUL NATIONAL UNIVERSITY		314
18	NATIONAL CHENG KUNG UNIVERSITY		315
19	KYUSHU UNIVERSITY		323
20	HONG KONG UNIVERSITY OF SCIENCE & TECHNOLOGY		345
21	NATIONAL SUN YAT-SEN UNIVERSITY		352
22	ZHEJIANG UNIVERSITY		358
23	NATIONAL TAIWAN NORMAL UNIVERSITY		375
24	SHANGHAI JIAO TONG UNIVERSITY		379
25	KOBE UNIVERSITY		412
26	NATIONAL TSING HUA UNIVERSITY TAIWAN		444
27	HIROSHIMA UNIVERSITY		454
28	UNIVERSITY OF SCIENCE & TECHNOLOGY OF CHINA		457
29	NANYANG TECHNOLOGICAL UNIVERSITY		459
30	CITY UNIVERSITY OF HONG KONG		462
31	TAMKANG UNIVERSITY		463
32	HONG KONG POLYTECHNIC UNIVERSITY		496
33	UNITED NATIONS UNIVERSITY		498
34	NATIONAL CENTRAL UNIVERSITY		507
35	RITSUMEIKAN UNIVERSITY		510
36	KASETSART UNIVERSITY		516
37	CHULALONGKORN UNIVERSITY		527
38	NATIONAL CHENGCHI UNIVERSITY		537
39	FUDAN UNIVERSITY		538
40	SHANDONG UNIVERSITY		591
41	HONG KONG BAPTIST UNIVERSITY		592
42	NANJING UNIVERSITY		593
43	NATIONAL CHUNG CHENG UNIVERSITY		607
44	NATIONAL CHUNG HSING UNIVERSITY		624
45	WASEDA UNIVERSITY		629
46	WUHAN UNIVERSITY		633
47	POHANG UNIVERSITY OF SCIENCE & TECHNOLOGY		637
48	I-SHOU UNIVERSITY		647
49	JAPAN ADVANCED INSTITUTE OF SCIENCE & TECHNOLOGY		669
50	PRINCE OF SONGKLA UNIVERSITY		672
51	INDIAN INSTITUTE OF TECHNOLOGY BOMBAY		674
52	XIAMEN UNIVERSITY		678
53	XI'AN JIAOTONG UNIVERSITY		681
54	UNIVERSITY OF ELECTRO-COMMUNICATIONS		695
55	INDIAN INSTITUTE OF SCIENCE BANGALORE		696
56	YONSEI UNIVERSITY		711
57	NANKAI UNIVERSITY		716
58	KOREA UNIVERSITY		724
59	RYUKOKU UNIVERSITY		730
60	BEIJING NORMAL UNIVERSITY		740
61	YUAN ZE UNIVERSITY		744
62	NAGAOKA UNIVERSITY OF TECHNOLOGY		749
63	TOKAI UNIVERSITY		751
64	GUNMA UNIVERSITY		762
65	HOSEI UNIVERSITY		766
66	NIHON UNIVERSITY		768
67	ASIAN INSTITUTE OF TECHNOLOGY THAILAND		772
68	DOSHISHA UNIVERSITY		776
69	YAMAGATA UNIVERSITY		793
70	FU JEN CATHOLIC UNIVERSITY		795
71	HARBIN INSTITUTE OF TECHNOLOGY		796
72	CHIANG MAI UNIVERSITY		805
73	PUSAN NATIONAL UNIVERSITY		807
74	SHINSHU UNIVERSITY		834
75	OKAYAMA UNIVERSITY		836
76	HOKKAIDO UNIVERSITY		841
77	NIIGATA UNIVERSITY		853
78	THAMMASAT UNIVERSITY		866
79	MIE UNIVERSITY		869
80	KYUSHU INSTITUTE OF TECHNOLOGY		870
81	SOUTHEAST UNIVERSITY		871
82	NARA INSTITUTE OF SCIENCE & TECHNOLOGY		876
83	ASSUMPTION UNIVERSITY OF THAILAND		877
84	RENMIN UNIVERSITY OF CHINA		881
85	KHON KAEN UNIVERSITY		887
86	PROVIDENCE UNIVERSITY		892
87	CHIBA UNIVERSITY		896
88	EAST CHINA NORMAL UNIVERSITY		908
89	MAHIDOL UNIVERSITY		916
90	HUAZHONG UNIVERSITY OF SCIENCE & TECHNOLOGY		920
91	TONGJI UNIVERSITY		921
92	MEIJI UNIVERSITY		926
93	CHINA AGRICULTURAL UNIVERSITY		931
94	GIFU UNIVERSITY		938
95	GADJAH MADA UNIVERSITY		939
96	EHIME UNIVERSITY		949
97	FENG CHIA UNIVERSITY		954
98	OSAKA CITY UNIVERSITY		967
99	INDIAN INSTITUTE OF TECHNOLOGY KANPUR		981
100	SOPHIA UNIVERSITY		991

เก็บมาฝากจาก http://www.webometrics.info/top100_continent.asp?cont=asia
เชื่ออะไรไม่ค่อยได้เท่าไหร่ เอาไว้ดูขำ ๆ

ความรู้อยู่ที่ตัวบุคคล สถาบันคือความภูมิใจ
จุฬาฯติด Top 50 ของ Asia ตลอดกาล ข้อมูล ณ เดือนกรกฎาคม 2007 ครับ แต่ไม่มีความหมายอะไรถ้าเราจบไปแล้วไม่มีความรู้อะไร ไม่เป็นทั้งคนเก่ง และคนดี ก็ไม่ได้ทำให้สถาบันน่าภูมิใจ และยังเป็นการลดเกียรติแห่งสถาบันและเพื่อนร่วมสถาบัน