2_Transaction Analysis

การออกแบบทรานแซกชั่นควรเริ่มต้นด้วยการวิเคราะห์ก่อน ซึ่งเราสามารถเริ่มวิเคราะห์ทรานแซกชั่นได้เร็วมากตั้งแต่เฟส requirement หรือช่วงต้นๆ ของโครงการเลยทีเดียว นั่นหมายถึง ไม่ต้องรอให้เก็บ requirement ให้จบ หรือในระบบขนาดใหญ่อย่าง enterprise system หรือ business system ที่ซับซ้อน ก่อนเริ่มทำ requirement ควรทำ business process modeling & analysis ก่อน นั่นคือ ทำความเข้าใจกับ business process และรายละเอียดต่างๆ ที่เกี่ยวข้องก่อน ในขณะที่วิเคราะห์ทำความเข้าใจ business process ก็ควรวิเคราะห์ทำความเข้าใจกับ business transaction ด้วย

เราอาจแบ่งทรานแซกชั่นออกเป็น 2 ขอบเขตใหญ่ๆ ได้แก่ business transaction และ system transaction

Business transaction นับตั้งแต่กระบวนการเริ่มต้น อาทิ ในระบบโอนเงินออนไลน์ เริ่มต้นจากผู้ใช้เลือกเมนู เลือกบัญชีต้นทาง ระบบก็จะดึงข้อมูลเงินคงเหลือมาแสดง เลือกบัญชีปลายทาง ระบบก็จะตรวจสอบธนาคารและบัญชีปลายทาง จากนั้นผู้ใช้ก็ป้อนจำนวนเงินที่ต้องการโอน แล้วก็ยืนยันการโอน ระบบก็จะส่งรหัส OTP มาให้ทางโทรศัพท์มือถือ แล้วจึงป้อนเพื่อยืนยันทางหน้าจอ จึงจบกระบวนการ จากตัวอย่าง จะเห็นว่ามีการส่ง request และรับ response ไปกลับกันหลายรอบ แสดงว่า business transaction นี้เป็นแบบ stateful transaction โดย business transaction เริ่มต้นที่การเริ่มใช้แบบฟอร์ม และจบลงด้วยการตรวจสอบรหัส OTP

System transaction เกิดขึ้นเมื่อระบบรับ OTP ที่ป้อนโดยผู้ใช้ และเริ่ม begin transaction จริงๆ จังหวะนี้ และจบการทำงานทันทีภายใน request เดียว ไม่ต้องมีการรับ/ส่ง request/response กันหลายรอบ แสดงว่า system transaction เป็นแบบ stateless transaction แต่จังหวะ business transaction อาจมีการพักข้อมูลชั่วคราวที่ระดับ user session ใน web application ก็ได้

การวิเคราะห์ทรานแซกชั่นจึงไม่ควรเริ่มต้นที่ system transaction เพราะจะทำให้ไม่เข้าใจที่มาที่ไปอย่างละเอียดครบถ้วนจริงๆ และการวิเคราะห์และออกแบบทรานแซกชั่นจำเป็นต้องวิเคราะห์และทำความเข้าใจ business process กับ business rule เสมอ (แต่มักพบว่าข้อมูลเหล่านี้มักมาไม่ถึงมือคนออกแบบและโปรแกรมเมอร์ ส่วน tester ก็ต้องทราบข้อมูลเหล่านี้ด้วยเช่นกัน เพื่อประโยชน์ต่อการออกแบบ test scenario/test case)

หากสังเกตให้ดีจะพบว่าเราสามารถวิเคราะห์และออกแบบทรานแซกชั่นได้ตั้งแต่ต้นๆ โครงการกันเลยทีเดียว วางจังหวะตรงไหนจะ begin-commit-rollback business transaction จังหวะไหนจะ begin-commit-rollback system transaction หรือพูดง่ายๆ คือ วิเคราะห์ business process กับ requirement กันไป ก็วิเคราะห์และออกแบบทรานแซกชั่นเบื้องต้นพร้อมกันไปได้เลย หากติดขัดอะไรตรงไหนก็ปรับเปลี่ยนกันตั้งแต่เนิ่นๆ ได้ทันท่วงที ทำให้บริหารความเสี่ยงได้ดี นอกจากนี้ยังควรพิจารณาเรื่อง topology ของฮาร์ดแวร์และเน็ตเวิร์กประกอบด้วย ว่าใช้เครื่องกี่เครื่อง แต่ละเครื่องทำอะไรบ้าง แบ่งสถาปัตยกรรมระบบเป็นกี่เลเยอร์ และแบ่ง tier เป็นกี่ tier เป็นต้น เพราะมีผลต่อ performance มากๆ และอย่าโยกการวิเคราะห์และออกแบบทรานแซกชั่น โดยเฉพาะจังหวะ system transaction ไปให้โปรแกรมเมอร์ทำนะครับ เพราะหากโปรแกรมเมอร์ไม่มีข้อมูล business process กับ business rule และไม่ชำนาญใน domain knowledge ของระบบงานนั้นๆ หรือไม่ชำนาญด้านการออกแบบทรานแซกชั่นดีพอ ความหายนะจะถามหาได้นะ…

และยิ่งหากวิเคราะห์และออกแบบทรานแซกชั่นด้วยการวาดรูป business process model ด้วย BPMN (Business Process Model Notation) จะยอดเยี่ยมมาก เพราะช่วยให้เข้าใจง่าย แถม modeling tool หลายยี่ห้อสามารถทำ process simulation ได้ด้วย เป็น animation วิ่งกันให้เห็นจะๆ กันไปเลย ยกตัวเช่นยี่ห้อ VisualParadigm ส่วนของฟรีก็มีเช่น BPMN (bpmn.org)

*การวิเคราะห์ทรานแซกชั่นในรายละเอียดที่จะกล่าวถึงต่อไปนี้ จำเป็นต้องมีข้อมูลที่เพียบพร้อมมาประกอบการวิเคราะห์ จึงสามารถใช้หัวข้อต่างๆ เอาไปถามหรือให้คนเก็บ requirement ไปเก็บเพิ่มได้ เพราะหากเก็บมาไม่สมบูรณ์พอ ก็มีผลต่อการวิเคราะห์อย่างมาก ซึ่งปกติที่ทำๆ กันโดยส่วนมากก็ไม่ค่อยจะเก็บกันครบเท่าไร เพราะงาน requirement คือจุดอ่อนของการพัฒนาและทีมพัฒนาในองค์กรจำนวนมากเลยทีเดียว และจากที่ผมพบในองค์กรจำนวนมากคือ บุคลากรที่รับผิดชอบด้าน requirement มักมีความรู้และทักษะไม่เหมาะสมกับงานสักเท่าไหร่ เนื่องจากงาน requirement เป็นงานที่ต้องอาศัยความรู้และทักษะทั้งด้าน soft skill, เทคนิค และ การจัดการ…

วิเคราะห์ Business Process & Rule

วิเคราะห์ business process ทำให้ทราบ เช่น Business actor, Business worker, Business location, Business activity, Business rule, ฯลฯ

การวิเคราะห์ business process ทำให้เข้าใจขั้นตอนการปฏิบัติงานในมุมมองของผู้ใช้ยิ่งขึ้น

การวิเคราะห์ business rule ทำให้เข้าใจเงื่อนไขหรือตรรกะทางธุรกิจ ซึ่งมีผลต่อการประมวลผล

วิเคราะห์พฤติกรรมไคลเอนต์ (Client Behavior)

หากไม่มี event เกิดขึ้น ระบบก็จะไม่เกิดการประมวลผล โดย Event เกิดจาก client ซึ่ง event มีหลายประเภท เช่น periodic, sporadic, stochastic

การทำความเข้าใจกับ event สามารถใช้การวิเคราะห์พฤติกรรมของ client ได้ โดยต้องดูว่า client มีพฤติกรรมในการใช้ระบบอย่างไร ลักษณะใด นอกจากควรทำความเข้าใจกับพฤติกรรมของ client ควรพิจารณาปัจจัยอื่น เช่น สถานที่ของ client หรือ client location, ประเภทของ client, ปริมาณของ client, client device (เช่น พีซี, โทรศัพท์มือถือ, ตู้ kiosk ฯลฯ), บทบาท หรือ role ของ client, ความต้องการ หรือ concern ของ client, ฯลฯ

ตัวอย่าง client behavior ซึ่งในความเป็นจริงอาจเก็บให้ละเอียดมาก/น้อยกว่านี้ก็ได้

ClientBehavior1

ClientBehavior2

วิเคราะห์ Service

ต้องระบุรายละเอียดเกี่ยวกับเซอร์วิสที่เกี่ยวข้องกับทรานแซกชั่น เช่น มีเซอร์วิสประเภทใดบ้าง, พฤติกรรมของเซอร์วิสและการให้บริการมีลักษณะอย่างไร, ใครเป็น client ของเซอร์วิส, เซอร์วิสไปเรียกใช้ใครต่อ มี coupling/dependency กับใครบ้าง หรือกับ resource ใดบ้าง, เซอร์วิสอยู่บนเครื่องเดียวกัน หรือกระจายตัวไปอยู่ตรงไหนบ้าง

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

ตัวอย่าง เซอร์วิสโดยทั่วไป เช่น

  • User Screen Service
  • Web Application Service
  • Web Service
  • Business Service
  • Domain Service : Business Logic, Data Logic
  • Resource Service เช่น database service, message queue service, SMS service, email service, directory service
  • Architectural Mechanism Service / Common Service / Non-Functionality เช่น
  • Proxy, Façade, Front Controller, Filter, Adapter, Exception Handling, Authentication, Authorization, Logging, Transaction Management, I/O, Network, Distribution, Data Exchange ฯลฯ

วิเคราะห์ Resource System & Connection

ระบุว่ารายละเอียดของ resource ที่ระบบและทรานแซกชั่นต้องใช้ เช่น มี resource อะไรบ้าง, มี resource ประเภทใดบ้าง, resource อยู่ที่ไหนบ้าง, ระบบมีพฤติกรรมการใช้ resource อย่างไร, Resource มีพฤติกรรมอย่างไร ลักษณะใด, constraint เกี่ยวกับ resource มีหรือไม่ อะไรบ้าง, ขอบเขตของอำนาจของระบบหรือคอมโพเน้นต์ ในการเข้าใช้ resource มีแค่ไหน(Autonomy for Resource Access) นอกจากนี้ยังต้องทราบค่าคอนฟิกของ resource นั้นๆ ด้วย เพื่อจะได้ออกแบบการเรียกใช้ resource ให้มีประสิทธิที่สุด หลักในการจำง่ายๆ คือ acquire resource ให้เร็วที่สุด, ถ้าจะล็อกก็ต้องรีบล็อกให้เร็ว, ใช้ให้เสร็จเร็วๆ, ปลดล็อกเร็วๆ ยิ่งถ้าเป็น shared resource ยิ่งต้องออกแบบการเรียกใช้ให้ดียิ่งขึ้น เพื่อป้องกันการเกิด latency time (เวลาหน่วง) ซึ่งมีผลต่อ response time ทำให้ช้าได้

ตัวอย่าง 1

AnalyzeResource_and_System

ตัวอย่าง 2

AnalyzeResource_and_System2

วิเคราะห์ Transaction Data & Data Transformation

การวิเคราะห์ transaction data / process data ทำให้ทราบ เช่น มีการใช้ข้อมูลอะไร, ชนิด/ฟอร์แมตอะไร, มีลำดับการใช้ข้อมูลอย่างไร, มี data granularity อย่างไร, ระบุการใช้ transaction session และ unit of work

วิเคราะห์ data transformation ทำให้ทราบ เช่น การ convert/exchange ข้อมูล, จุดที่มีการ convert/exchange ข้อมูล, การไหลของข้อมูล

ประโยชน์ของการวิเคราะห์ transaction data กับ data transformation เพื่อช่วยให้จัดการ performance ของการประมวลผลทรานแซกชั่น เพราะ transaction data ถ้ามีขนาดใหญ่หรือมีจำนวนมาก ก็จะเปลืองหน่วยความจำและ I/O รวมถึงเน็ตเวิร์ก ส่วน data transformation ถ้ามีมากก็จะเกิดโอเวอร์เฮดในการประมวลผลซึ่งเปลืองซีพียู และถ้าข้อมูลใหญ่ก็เปลืองเหมือน transaction data การเลือกใช้ฟอร์แมตหรือ data type อะไรก็ต้องเลือกให้เหมาะสม โปรแกรมเมอร์หรือคนออกแบบสมัยนี้ชอบใช้อะไรที่มันง่ายต่อการเขียนโปรแกรม ซึ่งมักง่าย ไม่ดีๆ ควรเลือกให้เหมาะสมดีกว่า

ตัวอย่าง 1

AnalyzeTXData_and_DataTransformation

ตัวอย่าง 2

AnalyzeTXData_and_DataTransformation2

ในตัวอย่างที่ 2 Browser ส่งข้อมูลออกมาเป็นพารามิเตอร์อยู่ในเฮดเดอร์ของโปรโตคอล HTTP จากนั้น Web App Engine ก็ครอบ type ด้วยการใช้ HttpServletRequest ลักษณะครอบ type หรือ encapsulate type แบบนี้ไม่ค่อยเปลือง performance เท่าไร จากนั้นก็ส่งไปให้ ABCFrontController ทำการดึงข้อมูลออกมา convert เป็นอ็อบเจ็คต์รวมถึงมีการแปลง data type ให้กับฟีลด์ต่างๆ จังหวะเริ่มเปลือง performance แล้ว จากนั้นก็ส่งไปให้ ABCRequestProcessor เพื่อเลือกว่าจะส่งให้ WAS ตัวไหน จากนั้นเลือกได้ก็ส่งไปให้กับ CreateOrderWAS เพื่อทำ application logic จากนั้นก็ครอบ type ด้วยการเอา ServiceInput มาครอบ แล้วส่งไปให้ BusinessServiceProxy เพื่อส่ง ServiceInput ออกไปนอกเครื่องผ่านเน็ตเวิร์กไปให้กับ BusinessServiceFacade ที่ทำหน้าที่ถอดอ็อบเจ็คต์จาก ServiceInput ออกมา แล้วส่งอ็อบเจ็คต์ Order ไปให้ OrderService เพื่อทำ business logic และ ทรานแซกชั่น จากนั้นก็ส่งอ็อบเจ็คต์ Order ไปให้ OrderDAO เพื่อดึงฟีลด์ต่างๆ มาสร้างเป็นคำสั่ง SQL ที่เป็น String แล้วส่งผ่าน database driver ไปให้ Oracle ประมวลผล จากนั้น call ก็จะกลับมาที่ OrderService เพื่อทำขั้นตอนต่อไปโดยถอดอ็อบเจ็คต์ ProductList ออกมาจากอ็อบเจ็คต์ Order เพื่อส่งให้ InventorySystemProxy เพื่อนำไป convert เป็น XML ซึ่งมีโอเวอร์เฮดพอสมควรหากข้อมูลมีขนาดใหญ่ จากนั้นจึงส่งไปให้กับระบบ InventorySystem

จากรูปในตัวอย่างข้างบน จุดที่น่าสนใจที่เราควรฝึกตั้งข้อสันนิษฐานว่าน่าจะมีผลต่อ performance ซึ่งมีอยู่ 3 จุด ได้แก่ จังหวะสร้างอ็อบเจ็คต์ Order, จังหวะสร้างคำสั่ง SQL และจังหวะแปลงอ็อบเจ็คต์ ProductList เป็น XML แล้วเราก็เอาข้อสันนิษฐานนี้ไปสร้าง test case เพื่อทดสอบ ถ้าผลออกมาไม่ดีก็ทำการจูน

วิเคราะห์ Architectural Layer & Tier

วิเคราะห์ architectural layer เพื่อดูพฤติกรรมของการ call ระหว่างเลเยอร์

วิเคราะห์ tier เพื่อดูว่ามี client device, node, resource อะไรบ้าง และเพื่อวิเคราะห์เน็ตเวิร์กระหว่าง tier

ตัวอย่าง

AnalyzeLayer_and_Tier

สร้าง Scenario เพื่ออธิบาย Transaction Concern

วิเคราะห์ความต้องการด้านต่างๆ และ concern ของ stakeholder เพื่อระบุจุดที่น่าสนใจที่มีผลต่อการจัดการทรานแซกชั่น โดยพิจารณาจากความเสี่ยง, performance, และการเข้าใช้ resource

วิเคราะห์และอธิบายรายละเอียดด้วยการจำลองสถานการณ์ (scenario) ซึ่งประกอบด้วยคุณสมบัติ เช่น

  • Transaction name
  • Relevant use cases
  • Relevant non-functional requirements
  • Relevant business process and rules
  • Event source and event behavior
  • Process Flow
  • Transaction scope within process
  • Concerned resources
  • อาจมีคุณสมบัติอื่นเพิ่มเติมอีกได้
  • Non-functional requirements หรือ quality attributes ที่มักมีผลต่อทรานแซกชั่น เช่น
  • performance, reliability, availability, modifiability
  • interoperability, integrability, configurability, scalability, testability, security

ตัวอย่าง 1

SampleScenario1

ตัวอย่าง 2

SampleScenario2

ตัวอย่าง 3

SampleScenario3

การสร้าง transaction scenario ช่วยให้อธิบายรายละเอียดทรานแซกชั่นได้ชัดเจนขึ้น ช่วยให้ผู้ใช้ ลูกค้า ผู้ออกแบบ และทีมงานเข้าใจตรงกันยิ่งขึ้น สำหรับการวิเคราะห์และออกแบบทรานแซกชั่นสามารถทำได้หลายจุดใน development process เช่น ออกแบบไปแล้วก็กลับมาวิเคราะห์ใหม่ได้เพื่อปรับปรุง หรือเขียนโปรแกรมไปแล้วทดสอบเบื้องต้นแล้ว ก็กลับมาแก้งานออกแบบใหม่ได้ เป็นต้น ซึ่งเป็นหลักของ Iterative Process นั่นเอง หรือจะเรียกว่าเป็นการทำ transaction refactoring ก็ได้ ทำมันอยู่เรื่อยๆ วนไปวนมา optimize ไปเรื่อยๆ จนกว่าทดสอบแล้วได้ค่าที่พอใจ

Transaction Traceability

Traceability คือ การตรวจสอบย้อนกลับ เมื่อนำมาประยุกต์กับการออกแบบและจัดการทรานแซกชั่น ทำให้ได้ประโยชน์หลายอย่าง เช่น:

  • การตัดสินใจในการควบคุมทรานแซกชั่นว่าจะจัดการอย่างไรจึงเหมาะสม
  • การวิเคราะห์ผลกระทบ (impact analysis) และ การบริหารความเสี่ยง
  • บริหารการเปลี่ยนแปลง (change management)
  • การพิจารณาการออกแบบตามหลัก ACID

TXTraceability

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

กำหนด Architectural Layer และ Tier ที่จะให้ทำ Transaction Control

ควรพิจารณาด้วยว่าจะ control หรือ orchestrate ทรานแซกชั่นที่เลเยอร์ใด และ tier ใด โดยทั่วคือไม่ที่ service layer ก็ domain layer แต่ถ้าเป็นสถาปัตยกรรมแบบ SOA (Service-Oriented Architecture) หรือแบบที่มีการใช้มิดเดิลแวร์ประเภท Business Process Management ก็จะทำให้เลเยอร์เฉพาะต่างๆ มีหลายชื่อเรียก โดยทั่วไปมักใช้ชื่อเลเยอร์ว่า Business Process Layer บ้าง, Process Orchestration Layer บ้าง ซึ่งเป็นเลเยอร์ที่อยู่สูงกว่า service layer และ domain layer ขึ้นไปอีก มักเป็นเลเยอร์ที่อยู่ใกล้ๆ จุดที่รับ request จากไคลเอนต์

ควรจัดวาง (allocate) การจัดการที่เลเยอร์ใดเลเยอร์หนึ่ง และ tier ใด tier หนึ่ง ไม่ควรกระจายอยู่ในหลายเลเยอร์ และหลาย tier มิฉะนั้นอาจทำให้จัดการยาก มีความซับซ้อนขึ้น และอาจเผลอทำให้เกิด dependency กับเทคโนโลยีโดยไม่ตั้งใจได้

LocateTXControl

การ control หรือ orchestrate ทรานแซกชั่นที่ service layer

  • ข้อดี คือ
    • เป็น single point of failure ทำให้จัดการทรานแซกชั่นเป็นระเบียบ อยู่ภายในเลเยอร์เดียวกัน และยังจัดการความปลอดภัยได้ดี
    • ออกแบบให้เป็น light weight layer เป็นการแยก concern ด้านการจัดการทรานแซกชั่นออกมาจาก domain object ทำให้ domain object เล็กลง และมี coupling กับ domain object น้อยลง
    • map ให้เข้ากับ use case ได้ง่าย
  • ข้อเสีย คือ
    • เกิดโอเวอร์เฮดที่เลเยอร์นี้สูง เนื่องจาก request ต้องวิ่งผ่านเลเยอร์นี้ก่อน
    • เป็นแนวทางในแบบ procedural / functional processing ไม่ใช่ object-orientation

การ control หรือ orchestrate ทรานแซกชั่นที่ domain layer

  • ข้อดี คือ
    • เป็นแนวทางในแบบ object-orientation
    • การจัดการทรานแซกชั่นอยู่ภายในหรือใกล้กับ domain object ทำให้ง่ายต่อการปรับปรุง domain object และการ reuse
    • ไม่ต้องมีเลเยอร์เพิ่มเติม ทำให้ performance ดีกว่า
  • ข้อเสีย คือ
    • ผู้ออกแบบต้องมีทักษะด้าน object-orientation เป็นอย่างดี มิฉะนั้นอาจส่งผลเสียมากต่อการเพิ่มระดับ coupling, การลดระดับการ reuse ลง และส่งผลเสียต่อ scalability
    • หากออกแบบไม่ดีอาจเกิดโอเวอร์เฮดที่เลเยอร์นี้สูง
    • บริหารจัดการยากกว่าเพราะมี coupling สูง เพราะไม่ได้แยก (separate) concern

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s