In this paper, we presented a forma

In this paper, we presented a formal model for capturing and reusing architectural
decision knowledge. Our approach extends existing proposals for retrospective
architectural decision capturing with a formal definition of architectural decision
models and modeling concepts for collaboration and reuse, e.g., levels, dependency
relations, integrity constraints, and production rules. We used this model to capture
389 SOA issues. Decision types such as executive decisions, pattern selection and
33
adoption decisions, technology selection and profiling decisions, asset selection and
configuration decisions appear in this model. Selected decisions from this SOA
decision model served us as examples.
The decision types introduced in Section 3, the relations defined in Section 4 and
the dependency patterns from Section 5 serve several purposes: First, they can help
knowledge engineers and software architects to detect design flaws (in reusable
assets, on individual development and integration projects). Furthermore, they have
educational character for consumers of architectural knowledge. Decision
identification, making, and enforcement tools can be built that guide decision makers
through their activities and verify integrity constraints along the way. Pruning can be
used to cut off alternatives and entire sub trees when a decision is made. This
simplifies the rather complex task of managing a complex decision model.
Future work concerns formalizing additional characteristics of tree-based
architectural decision models and the relationship between decision models and other
model types used to document the various views on software architecture such as
Kruchten’s 4+1 views [10]. The design fragments from Jansen and Bosch and the
SPEM integration from de Boer et al. can be leveraged to do so. Additional
constraints on various relations can be expressed. Finally, integrating SOAD with
natural controlled language such as Attempto Controlled English (ACE) [7] is another
promising area of future research: If SOAD decision drivers and related best practices
recommendations are articulated in a natural controlled language such as ACE, a
reasoning engine can analyze them and suggest certain alternatives to the architect.
We envision several advanced usage scenarios for the concepts presented in this
paper. Project managers can use decision models for planning purposes. Work
breakdown structures and effort estimation reports can be created, as open decisions
correspond to required activities. Health checking is another application area: If there
are many, frequent changes, or many questions are still unresolved in late project
phases, the project is likely to be troubled. Product selection decisions define which
software licenses are required, and on which hardware nodes the required software
has to be installed. Moreover, the outcome of product-specific asset configuration
decisions can serve as input to software configuration management. The model can
also serve enterprise architects; they can maintain a company-specific instance of the
decision model, consisting of a subset of issues and alternatives. Such an approach
authorizes solution architects on projects to make decisions (“freedom of choice”)
without sacrificing architectural integrity (“freedom from choice”). Finally, the
reusable decision model for SOA can be used as a supplemental design method for
SOA construction which complements and details existing service modeling methods.

Results (Thai) 1:

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

33 ยอมรับการตัดสินใจเลือกเทคโนโลยีและการตัดสินใจโปรไฟล์การเลือกสินทรัพย์และการตัดสินใจการกำหนดค่า
ปรากฏในรูปแบบนี้ การตัดสินใจเลือกจากนี้ SOA แบบ
การตัดสินใจของเราทำหน้าที่เป็นตัวอย่าง
ประเภทการตัดสินใจนำมาใช้ในส่วนที่ 3ความสัมพันธ์ที่กำหนดไว้ในมาตรา 4 และรูปแบบการพึ่งพา
จากมาตรา 5 เพื่อให้บริการหลายครั้งแรกที่พวกเขาสามารถช่วยให้ความรู้
วิศวกรและสถาปนิกซอฟต์แวร์ในการตรวจสอบข้อบกพร่องการออกแบบ (นำมาใช้ใหม่ใน
สินทรัพย์ในการพัฒนาและบูรณาการแต่ละโครงการ) นอกจากนี้พวกเขามีตัวละคร
การศึกษาสำหรับผู้บริโภคที่มีความรู้ทางสถาปัตยกรรม ตัดสินใจ
ตัวทำและเครื่องมือการบังคับใช้สามารถสร้างขึ้นที่ผู้มีอำนาจตัดสินใจคู่มือ
ผ่านกิจกรรมของพวกเขาและตรวจสอบข้อ จำกัด ของความสมบูรณ์ไปพร้อมกัน การตัดแต่งกิ่งสามารถ
ใช้ในการตัดทางเลือกและต้นไม้ย่อยทั้งหมดเมื่อตัดสินใจที่จะทำ นี้ช่วยลดความยุ่งยาก
งานที่ค่อนข้างซับซ้อนในการจัดการรูปแบบการตัดสินใจที่ซับซ้อน
ความกังวลการทำงานในอนาคตอย่างเป็นทางการเพิ่มเติมลักษณะของต้นไม้ที่ใช้
รูปแบบการตัดสินใจของสถ​​าปัตยกรรมและความสัมพันธ์ระหว่างรูปแบบการตัดสินใจและแบบอื่น
แบบที่ใช้ในการบันทึกมุมมองที่หลากหลายในสถาปัตยกรรมซอฟต์แวร์เช่น
Kruchten 4 1 ครั้ง [10] ชิ้นส่วนการออกแบบจาก jansen และบ๊อชและบูรณาการ Spem
จากโบเออร์และอัล สามารถ leveraged ที่จะทำเช่นนั้น เพิ่มเติม
ข้อ จำกัด ในความสัมพันธ์ต่างๆสามารถแสดง ในที่สุดบูรณาการกับการ soad
ภาษาควบคุมธรรมชาติเช่น attempto ควบคุมภาษาอังกฤษ (เอซ) [7] เป็นอีกหนึ่งพื้นที่
แนวโน้มของการวิจัยในอนาคตถ้าคนขับรถตัดสินใจ soad และการปฏิบัติที่ดีที่สุดที่เกี่ยวข้อง
แนะนำจะก้องในภาษาควบคุมธรรมชาติเช่นเอซ,
เครื่องยนต์เหตุผลสามารถวิเคราะห์พวกเขาและแนะนำทางเลือกบางอย่างเพื่อสถาปนิก
เราวาดภาพสถานการณ์การใช้งานหลายขั้นสูงสำหรับแนวคิดที่นำเสนอในครั้งนี้
กระดาษ ผู้จัดการโครงการสามารถใช้รูปแบบการตัดสินใจในการวางแผนเพื่อ
งานโครงสร้างรายละเอียดและรายงานการประเมินความพยายามที่สามารถสร้างขึ้นได้เปิดการตัดสินใจ
สอดคล้องกับกิจกรรมที่จำเป็นต้องใช้ การตรวจสอบสุขภาพเป็นพื้นที่โปรแกรมอื่นถ้ามี
เป็นจำนวนมากการเปลี่ยนแปลงบ่อยหรือคำถามจำนวนมากยังคงได้รับการแก้ไขในโครงการปลาย
ขั้นตอนโครงการมีแนวโน้มที่จะเป็นทุกข์ การตัดสินใจเลือกใช้ผลิตภัณฑ์ที่กำหนดซึ่ง
ใบอนุญาตซอฟต์แวร์ที่จำเป็นและที่โหนดฮาร์ดแวร์ซอฟต์แวร์ที่จำเป็น
จะต้องมีการติดตั้ง ยิ่งไปกว่านั้นผลของการกำหนดค่าสินทรัพย์เฉพาะผลิตภัณฑ์
ตัดสินใจสามารถใช้เป็นข้อมูลในการบริหารจัดการการกำหนดค่าซอฟต์แวร์ รูปแบบที่สามารถ
ยังทำหน้าที่สถาปนิกองค์กรที่พวกเขาสามารถรักษาเช่น บริษัท ที่เฉพาะเจาะจงของ
รูปแบบการตัดสินใจประกอบด้วยชุดย่อยของปัญหาและทางเลือก วิธีการดังกล่าว
อนุญาตสถาปนิกแก้ปัญหาในโครงการที่จะทำให้การตัดสินใจ ("เสรีภาพในการเลือก")
โดยไม่ต้องเสียสละความสมบูรณ์ทางสถาปัตยกรรม ("เสรีภาพจากตัวเลือก") ที่สุด
แบบจำลองการตัดสินใจนำมาใช้ใหม่เพื่อ SOA สามารถใช้เป็นวิธีการออกแบบเพื่อเสริม
SOA ก่อสร้างซึ่งเติมเต็มและรายละเอียดที่มีอยู่วิธีการสร้างแบบจำลองการให้บริการ

Results (Thai) 2:

ในเอกสารนี้ เรานำเสนอแบบเป็นทางการสำหรับการจับภาพ และนำมาใช้ใหม่สถาปัตยกรรม
ตัดสินใจรู้ วิธีของเราขยายข้อเสนอที่มีอยู่สำหรับย้อนรอย
ตัดสินใจสถาปัตยกรรมจับกับคำจำกัดความอย่างเป็นทางการของสถาปัตยกรรมตัดสิน
รูปแบบและแนวคิดการสร้างแบบจำลองสำหรับอ้างอิงร่วมกันและนำมาใช้ใหม่ เช่น ระดับ
ความสัมพันธ์ ความสมบูรณ์ของข้อจำกัด และกฎการผลิต เราใช้รุ่นนี้จับ
389 SOA ปัญหา ชนิดเช่นตัดสินใจบริหารการตัดสินใจ รูปแบบการเลือก และ
33
ตัดสินใจยอมรับ การเลือกเทคโนโลยี และสร้างโพรไฟล์การตัดสินใจ การเลือกสินทรัพย์ และ
กำหนดค่าตัดสินใจที่ปรากฏในรูปแบบนี้ เลือกตัดสินใจจาก SOA นี้
ตัดสินใจรูปแบบบริการเราเป็นอย่างนั้น
ตัดสินใจแบบในหมวดที่ 3 ความสัมพันธ์ที่กำหนดใน 4 ส่วน และ
รูปอ้างอิงจาก 5 ส่วนบริการต่าง ๆ: ครั้งแรก พวกเขาสามารถช่วย
รู้วิศวกรและสถาปนิกซอฟต์แวร์ตรวจพบข้อบกพร่องในการออกแบบ (ใน reusable
สินทรัพย์ โครงการพัฒนาและบูรณาการแต่ละ) นอกจากนี้ พวกเขามี
ศึกษาอักขระสำหรับผู้บริโภคความรู้สถาปัตยกรรม ตัดสินใจ
รหัส การ และใช้เครื่องมือสามารถสร้างคู่มือที่ผู้ตัดสินใจ
ผ่านกิจกรรม และตรวจสอบความสมบูรณ์ของข้อจำกัดตามวิธีการ สามารถตัด
ใช้ในการตัดเลือกและต้นไม้ย่อยทั้งหมดเมื่อทำการตัดสินใจได้ นี้
งานค่อนข้างซับซ้อนของการจัดการแบบจำลองการตัดสินใจที่ซับซ้อนช่วยให้ง่ายขึ้น
ในอนาคตทำงานเกี่ยวข้องกับลักษณะ formalizing เพิ่มเติมของต้นไม้
รูปแบบสถาปัตยกรรมการตัดสินใจและความสัมพันธ์ระหว่างรูปแบบการตัดสินใจและอื่น ๆ
รุ่นชนิดที่ใช้เอกสารมุมมองต่าง ๆ บนสถาปัตยกรรมซอฟต์แวร์เช่น
ของ Kruchten 1 4 ดู [10] ออกแบบชิ้นส่วนจากแจนเซนและ Bosch และ
สามารถ leveraged SPEM รวมจากเดอโบ et al. ดังนั้น เพิ่มเติม
สามารถแสดงข้อจำกัดความสัมพันธ์ต่าง ๆ ได้ สุดท้าย รวม SOAD ด้วย
ภาษาธรรมชาติควบคุมเช่น Attempto ควบคุมภาษาอังกฤษ (ACE) [7] เป็นอีก
สัญญาพื้นที่วิจัยในอนาคต: SOAD ถ้าโปรแกรมควบคุมตัดสินใจและวิธีปฏิบัติที่เกี่ยวข้อง
แนะนำจะพูดชัดแจ้งในภาษาธรรมชาติควบคุมเช่น ACE การ
ด้านโปรแกรมสามารถวิเคราะห์ได้ และแนะนำบางอย่างแทนสถาปนิก
เราวาดภาพสถานการณ์การใช้งานขั้นสูงสำหรับแนวคิดที่นำเสนอในนี้
กระดาษ ผู้จัดการโครงการสามารถใช้แบบจำลองการตัดสินใจสำหรับการวางแผน งาน
แบ่งโครงสร้างและรายงานการประเมินความพยายามได้ตัดสินใจสร้าง เปิดเป็น
สอดคล้องกับกิจกรรมที่ต้องการ ตรวจสอบสุขภาพเป็นแอพพลิเคชันอื่น: ถ้ามี
จะเปลี่ยนแปลงบ่อย มากมาย หรือหลายคำถามที่ยังแก้ไขในโครงการสาย
ระยะ โครงการมีแนวโน้มจะเป็นปัญหา ตัดสินใจเลือกผลิตภัณฑ์กำหนดซึ่ง
ใช้งานซอฟต์แวร์จำเป็น และโหนดที่ฮาร์ดแวร์ซอฟต์แวร์จำเป็น
มีให้ติดตั้ง นอกจากนี้ ผลของการตั้งค่าคอนฟิกสินทรัพย์เฉพาะผลิตภัณฑ์
ตัดสินใจสามารถใช้เป็นข้อมูลป้อนเข้าเพื่อจัดการการตั้งค่าคอนฟิกซอฟต์แวร์ แบบจำลองสามารถ
นอกจากนี้ยัง ให้บริการองค์กรสถาปนิก พวกเขาสามารถรักษาเฉพาะบริษัทอินสแตนซ์ของการ
ตัดสินใจรุ่น ประกอบด้วยชุดย่อยของปัญหาและทางเลือก วิธีการ
โซลูชันสถาปนิกโครงการ ("เสรีภาพเลือก") ในการตัดสินใจอนุมัติ
โดยที่ยังคงความสมบูรณ์ของสถาปัตยกรรม ("เสรีภาพจากตัวเลือก") ในที่สุด การ
สามารถใช้รูปประกอบการตัดสินใจสำหรับ SOA เป็นวิธีการออกแบบเพิ่มเติมสำหรับ
ก่อสร้าง SOA ซึ่งเสริม และรายละเอียดบริการที่มีวิธีการสร้างโมเดลได้