การใช้ Groovy AOP เพื่ออธิบายตรรกเชิงธุรกรรมในเกรลส์

เนื่องจากผมจะไปร่วมการประชุม AOSD '08 และไปนำเสนองานวิจัยใน SLAT 2008 workshop วันนี้ได้รับการบ้านมาหนึ่งชิ้นจากผู้จัด workshop โดยให้เตรียมการอธิบายสถานการณ์ในการพัฒนาซอฟต์แวร์ที่เจอมา ว่าการพัฒนาซอฟต์แวร์เชิงลักษณะเกี่ยวข้องกับสมบัติทางวิศวกรรมซอฟต์แวร์เชิงคุณภาพ (เลือกมา 1 ตัว) อย่างไร

ผมเลือกที่จะอธิบาย Comprehensibility ที่สะท้อนออกมาจาก Groovy AOP เมื่อใช้งานกับ Grails เลยแปลงานตัวเองแล้วนำมาให้อ่านกันครับ

การใช้ Groovy AOP เพื่ออธิบายตรรกเชิงธุรกรรมในเกรลส์

เอกสารชิ้นนี้อธิบายปัญหาที่พบเมื่อนำ Groovy AOP ไปใช้กับเฟรมเวิร์คเกรลส์ซึ่งสะท้อน สมบัติ Comprehensibility

ในเฟรมเวิร์คเกรลส์นั้นมีองค์ประกอบ (artefact) ระดับสูง(ที่มีความหมายเชิงนามธรรมสูงกว่าคลาส) หลาย ๆ อย่างเช่น ตัวควบคุม (Controller) หรือ โดเมนคลาส เป็นต้น ภาษา AOP ที่จะนำไปใช้กับเกรลส์นั้นจำเป็นที่จะต้องสนับสนุนการประกาศ pointcut ระดับที่สูงขึ้นเพื่อใช้อธิบายองค์ประกอบเหล่านั้น นอกจากนี้ เกรลส์สนับสนุนการพัฒนาส่วนขยายผ่านระบบปลั๊กอิน และนักพัฒนาก็สามารถนิยามองค์ประกอบเพิ่มขึ้นมาในปลั๊กอินที่พัฒนาขึ้นใหม่ได้ ดังนั้นภาษา AOP จึงจำเป็นที่จะต้องมีความสามารถในการพัฒนาส่วนขยายเช่นกัน เพื่อให้รองรับจุดร่วม (join point) ที่เพิ่มเข้ามาจากองค์ประกอบเหล่านั้น

ยกตัวอย่างเช่น ในปัจจุบัน Groovy AOP สนับสนุน pointcut พื้นฐานดังเช่น:

- pcall(pattern)
- etc.

แต่ pointcut เหล่านี้ไม่ได้สะท้อนความหมายขององค์ประกอบในเกรลส์ ซึ่งนักพัฒนาจะต้องการ pointcut เช่น:
- controller(pattern)
- action(pattern)
- etc.

ต่อไปนี้คือตัวอย่างของเวบแอพพลิเคชั่นที่เขียนด้วยเกรลส์

class BookController {
  def list = {
    def books = Book.list()
    render(view:'book', model:[books: books])
  }
 
  def show = {
    ...
  }

  def update = {
    ...
  }
}

และนี่คือ aspect ที่เขียนด้วย Groovy AOP:

aspect SecurityAspect {
  def pc = pcall('BookController.*')
  around(pc) {
    // check access
  }
}

และ aspect ต่อไปนี้เขียนด้วย Groovy AOP และใช้ pointcut ระดับสูงขึ้น (เพื่อจับความหมายของ ตัวควบคุม และ action):

aspect SecurityAspect {
  def pc = controller('book') & action('*')
  around(pc) {
    // check access
  }
}

ตัวอย่างถัดมาคือ aspect เขียนด้วยไวยากรณ์อีกแบบของ Groovy AOP ด้วย pointcut ระดับสูงเช่นกัน แต่ไม่มีการนิยาม poincut แยก (ใช้แบบย่อ) ซึ่งแนวทางไวยากรณ์แบบนี้นำมาจากลักษณะภาษาที่นักพัฒนาเกรลส์คุ้นเคย

aspect SecurityAspect {
   around(controller:'book', action:'*') {
      // check access
   }
}

และนอกจากนี้ Groovy AOP ควรสนับสนุนความสามารถในการขยายระบบเพื่อให้ครอบคลุมองค์ประกอบซอฟต์แวร์ใหม่ ๆ ที่อาจเพิ่มเข้ามาได้ผ่านทางระบบปลั๊กอินของเกรลส์

บทสรุป

Groovy AOP นั้นสามารถปรับใช้งานกับเฟรมเวิร์คเกรลส์ได้เนื่องจากตัวมันเป็นระบบ AOP เอนกประสงค์สำหรับภาษากรูวี่ ตัว Groovy AOP สามารถใช้อธิบายตรรกะเชิงธุรกรรมได้ในรูปของ ลักษณะระดับแอพพลิเคชั่น อย่างไรก็ตาม ตัวเฟรมเวิร์คเกรลส์นั้นมีความเป็นพลวัตรสูงและนักพัฒนาสามารถเพิ่มองค์ประกอบซอฟต์แวร์ได้ด้วยการสร้างปลั๊กอินตัวใหม่ เพื่อให้ระบบ AOP รองรับกับความต้องการนี้ ตัวระบบควรมีความสามารถรองรับการนิยาม pointcut ในลักษณะเดียวกันกับสถาปัตยกรรมปลั๊กอิน

ตัวอย่างในบทความนี้สะท้อน Comprehensibility อย่างไร

- เพื่อให้ภาษา AOP เพิ่มความเข้าใจให้กับนักพัฒนา
ตัวระบบควรใช้ภาษาที่นักพัฒนาคุ้นเคย (โดยอ้างอิงจากภาษาหลัก หรือ เฟรมเวิร์คที่ระบบ AOP จะเข้าไปจัดการ)
- เพื่อสนับสนุนความสามารถในการเปลี่ยนแปลงและปรับแต่ง
ระบบควรเปิดช่องทางให้สามารถนิยาม PCD ใหม่ ๆ ได้
- AOSD สนับสนุน Comprehensibility ดีแค่ไหน อย่างไร ?
ขึ้นกับการอิมพลีเม้นต์และภาษาหลัก (เช่น Java / AspectJ, Groovy / Groovy AOP)
อย่างไรก็ตามในปัจจุบัน Groovy AOP ยังไม่สนับสนุนสมบัติข้อดีได้ดีพอ