2 Literature Review This section di

2 Literature Review
This section discusses the basic terms, existing SA methods and their analysis.
2.1 Quality Attributes (QA)
Non-functional characteristics of a component or a system are called quality attributes. Software quality is defined in IEEE 1061 as “the degree to which software possesses a desired combination of attributes” [4]. It is very important to differentiate between the Software Quality and Quality of SA. Quality of Software is derived from the SA whereas the quality of SA is explicitly required to be measured. Piattini et al. [5] conclude that most of the research has focused on Software Quality but there is much research work needed on the quality of SA.
2.2 Software Architecture (SA)
All software systems have SA that describes the fundamental organization of the system [4]. Designing SA to achieve required QA is one of the most demanding tasks [7]. The SA captures early design decisions and reflects major quality concerns, including functionality [10]. It recognizes functional requirements of a system [8] and is an important aspect of producing high quality software systems [9]. Bass et al. [10] define SA of a system as “the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them”. SA must ensure the level of quality to be delivered to the user, referred to as QoS [8]. Ladan et al. [14] propose qualitydriven software re-engineering process to support QoS.
2.3 Software Architecture with Respect to QoS
To construct software architectural structure for a system that fulfils the desired QA’s is often a challenging task. In addition to functional requirements, QA’s also affect
176 R. Ahmad et al.
the selection of appropriate SA. An appropriate architecture is not only governed by functional requirements but, to a large extent, by QA’s [15], [16], [17]. There are usually more than one QA involved in a system and the knowledge of the pros and cons of different architectural structures with respect to different QA’s is not mature enough [15]. In [15] Svahnberg et al. propose a decision support method that provides aid in the understanding of different architecture structures and to choose best-suited architecture to meet the quality requirements of the software system from a set of candidate SA structures. The proposed method enables a quantified understanding of different architecture candidates for a software system. The set of candidate SA structures and required QA’s are the main inputs of the process. The output of the process is an appropriate SA structure that fulfils the required QA’s and uncertainty indicator.
2.2 Overview of Analysis Methods
This section provides an overview of different existing SA methods. Scenario-Based Architecture Analysis Method (SAAM). SAAM appeared in 1993 [19] with the trend for a better understanding of general architectural concepts, as a foundation for proof that a software system meets more than just functional requirements [11], [18]. The goal of this method is to verify basic architectural assumptions and principles against the documents describing the desired properties of an application [11]. The strength of this method is to concentrate on any QA in the form of scenarios. The main inputs of SAAM are problem description, requirements statement and architecture description(s). SAAM Founded on Complex Scenarios (SAAMCS). SAAMCS is an extended version of SAAM that is directed to the way of looking for the scenarios and, to where their impact is evaluated. The important goal of SAAMCS is risk assessment. It considers that the complexity of scenarios is the most important factor for risk assessment [11], [20]. Extending SAAM by Integration in the Domain (ESAAMI). ESAAMI is a combination of analytical and reuse concepts and is achieved by integrating the SAAM in the domain-specific and reuse-based development process [11], [20]. The SAAM is the evaluation technique; the quality attributes and SA description are same in both SAAM and ESAAMI. However, ESAAMI adds the reuse of domain knowledge defined by SA’s and analysis templates. Software Architecture Analysis Method for Evolution and Reusability (SAAMER). SAAMER is an extended version of SAAM that supports two particular QAs. i.e., (i) evolution, and (ii) reusability [11], [22]. It provides a better support of how a system could restrain each of the quality objectives or the risk levels for evolution or how to reuse it [11]. It provides a framework of activities for architecture analysis process. This framework consists of gathering information about stakeholders, SA, quality, and scenarios, modeling usable artifacts, analysis, and evaluation activities [11].
ISARE: An Integrated Software Architecture Reuse and Evaluation Framework 177
Architecture Trade-Off Analysis Method (ATAM). ATAM is used to for architectural analysis of individual quality attributes. It wa

2 Literature Review 
This section discusses the basic terms, existing SA methods and their analysis. 
2.1 Quality Attributes (QA) 
Non-functional characteristics of a component or a system are called quality attributes. Software quality is defined in IEEE 1061 as “the degree to which software possesses a desired combination of attributes” [4]. It is very important to differentiate between the Software Quality and Quality of SA. Quality of Software is derived from the SA whereas the quality of SA is explicitly required to be measured. Piattini et al. [5] conclude that most of the research has focused on Software Quality but there is much research work needed on the quality of SA. 
2.2 Software Architecture (SA) 
All software systems have SA that describes the fundamental organization of the system [4]. Designing SA to achieve required QA is one of the most demanding tasks [7]. The SA captures early design decisions and reflects major quality concerns, including functionality [10]. It recognizes functional requirements of a system [8] and is an important aspect of producing high quality software systems [9]. Bass et al. [10] define SA of a system as “the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them”. SA must ensure the level of quality to be delivered to the user, referred to as QoS [8]. Ladan et al. [14] propose qualitydriven software re-engineering process to support QoS. 
2.3 Software Architecture with Respect to QoS 
To construct software architectural structure for a system that fulfils the desired QA’s is often a challenging task. In addition to functional requirements, QA’s also affect 
176 R. Ahmad et al. 
the selection of appropriate SA. An appropriate architecture is not only governed by functional requirements but, to a large extent, by QA’s [15], [16], [17]. There are usually more than one QA involved in a system and the knowledge of the pros and cons of different architectural structures with respect to different QA’s is not mature enough [15]. In [15] Svahnberg et al. propose a decision support method that provides aid in the understanding of different architecture structures and to choose best-suited architecture to meet the quality requirements of the software system from a set of candidate SA structures. The proposed method enables a quantified understanding of different architecture candidates for a software system. The set of candidate SA structures and required QA’s are the main inputs of the process. The output of the process is an appropriate SA structure that fulfils the required QA’s and uncertainty indicator. 
2.2 Overview of Analysis Methods 
This section provides an overview of different existing SA methods. Scenario-Based Architecture Analysis Method (SAAM). SAAM appeared in 1993 [19] with the trend for a better understanding of general architectural concepts, as a foundation for proof that a software system meets more than just functional requirements [11], [18]. The goal of this method is to verify basic architectural assumptions and principles against the documents describing the desired properties of an application [11]. The strength of this method is to concentrate on any QA in the form of scenarios. The main inputs of SAAM are problem description, requirements statement and architecture description(s). SAAM Founded on Complex Scenarios (SAAMCS). SAAMCS is an extended version of SAAM that is directed to the way of looking for the scenarios and, to where their impact is evaluated. The important goal of SAAMCS is risk assessment. It considers that the complexity of scenarios is the most important factor for risk assessment [11], [20]. Extending SAAM by Integration in the Domain (ESAAMI). ESAAMI is a combination of analytical and reuse concepts and is achieved by integrating the SAAM in the domain-specific and reuse-based development process [11], [20]. The SAAM is the evaluation technique; the quality attributes and SA description are same in both SAAM and ESAAMI. However, ESAAMI adds the reuse of domain knowledge defined by SA’s and analysis templates. Software Architecture Analysis Method for Evolution and Reusability (SAAMER). SAAMER is an extended version of SAAM that supports two particular QAs. i.e., (i) evolution, and (ii) reusability [11], [22]. It provides a better support of how a system could restrain each of the quality objectives or the risk levels for evolution or how to reuse it [11]. It provides a framework of activities for architecture analysis process. This framework consists of gathering information about stakeholders, SA, quality, and scenarios, modeling usable artifacts, analysis, and evaluation activities [11]. 
 ISARE: An Integrated Software Architecture Reuse and Evaluation Framework 177 
Architecture Trade-Off Analysis Method (ATAM). ATAM is used to for architectural analysis of individual quality attributes. It wa

0/5000

Từ: -

Sang: -

Kết quả (Việt) 1: [Sao chép]

Sao chép!

2 văn nhận xét Phần này thảo luận về các điều khoản cơ bản, phương pháp SA hiện có và phân tích của họ. 2.1 thuộc tính chất lượng (QA) Các đặc tính chức năng phòng không của một phần hoặc một hệ thống được gọi là chất lượng thuộc tính. Chất lượng phần mềm được định nghĩa trong IEEE 1061 như "học cho phần mềm nào sở hữu một sự kết hợp mong muốn của thuộc tính" [4]. Nó là rất quan trọng để phân biệt giữa chất lượng phần mềm và chất lượng của SA. Chất lượng của các phần mềm có nguồn gốc từ SA trong khi chất lượng SA là rõ ràng yêu cầu đo đạc. Piattini et al. [5] kết luận rằng hầu hết các nghiên cứu đã tập trung vào chất lượng phần mềm nhưng có nhiều nghiên cứu cần thiết về chất lượng của SA. 2.2 kiến trúc phần mềm (SA) Tất cả phần mềm hệ thống có SA mô tả tổ chức cơ bản của hệ thống [4]. Thiết kế SA để đạt được yêu cầu bảo đảm chất lượng là một trong những công việc đòi hỏi nhiều nhất [7]. SA bắt đầu thiết kế quyết định và phản ánh mối quan tâm lớn chất lượng, bao gồm chức năng [10]. Nó nhận ra các yêu cầu chức năng của một hệ thống [8] và là một khía cạnh quan trọng của sản xuất các hệ thống phần mềm chất lượng cao [9]. Bass et al. [10] xác định SA của một hệ thống như "cấu trúc hoặc cấu trúc của hệ thống, bao gồm các thành phần phần mềm, các thuộc tính có thể nhìn thấy bên ngoài của những thành phần, và các mối quan hệ giữa chúng". SA phải đảm bảo mức độ chất lượng phải được gửi đến người dùng, được gọi là QoS [8]. Đoàn et al. [14] đề xuất quy trình kỹ thuật lại phần mềm qualitydriven để hỗ trợ QoS. 2.3 kiến trúc phần mềm đối với QoS Xây dựng phần mềm kiến trúc cơ cấu cho một hệ thống fulfils bảo đảm chất lượng mong muốn thường là một nhiệm vụ đầy thử thách. Ngoài các yêu cầu chức năng, bảo đảm chất lượng của cũng ảnh hưởng đến 176 R. Ahmad et al. việc lựa chọn thích hợp SA. Một kiến trúc phù hợp được không chỉ quản lý bằng cách yêu cầu chức năng, nhưng đến một mức độ lớn, bằng cách bảo đảm chất lượng của [15] [16], [17]. Không có thường nhiều hơn một bảo đảm chất lượng tham gia vào một hệ thống và các kiến thức về những ưu và nhược điểm của cơ cấu kiến trúc khác nhau đối với khác nhau QA là không trưởng thành đủ [15]. [15] Svahnberg et al. đề xuất một phương pháp hỗ trợ quyết định cung cấp viện trợ trong sự hiểu biết của công trình kiến trúc khác nhau và lựa chọn tốt nhất phù hợp với kiến trúc để đáp ứng yêu cầu chất lượng của hệ thống phần mềm từ một tập hợp của các ứng cử viên SA cấu trúc. Các phương pháp được đề xuất cho phép một sự hiểu biết định lượng của kiến trúc khác ứng cử viên cho một hệ thống phần mềm. Các thiết lập của ứng cử viên SA cơ cấu và các yêu cầu bảo đảm chất là yếu tố đầu vào chính của quá trình. Đầu ra của quá trình là một thích hợp cấu trúc SA fulfils bảo đảm chất lượng cần thiết và chỉ số không chắc chắn. 2.2 Các tổng quan về các phương pháp phân tích This section provides an overview of different existing SA methods. Scenario-Based Architecture Analysis Method (SAAM). SAAM appeared in 1993 [19] with the trend for a better understanding of general architectural concepts, as a foundation for proof that a software system meets more than just functional requirements [11], [18]. The goal of this method is to verify basic architectural assumptions and principles against the documents describing the desired properties of an application [11]. The strength of this method is to concentrate on any QA in the form of scenarios. The main inputs of SAAM are problem description, requirements statement and architecture description(s). SAAM Founded on Complex Scenarios (SAAMCS). SAAMCS is an extended version of SAAM that is directed to the way of looking for the scenarios and, to where their impact is evaluated. The important goal of SAAMCS is risk assessment. It considers that the complexity of scenarios is the most important factor for risk assessment [11], [20]. Extending SAAM by Integration in the Domain (ESAAMI). ESAAMI is a combination of analytical and reuse concepts and is achieved by integrating the SAAM in the domain-specific and reuse-based development process [11], [20]. The SAAM is the evaluation technique; the quality attributes and SA description are same in both SAAM and ESAAMI. However, ESAAMI adds the reuse of domain knowledge defined by SA’s and analysis templates. Software Architecture Analysis Method for Evolution and Reusability (SAAMER). SAAMER is an extended version of SAAM that supports two particular QAs. i.e., (i) evolution, and (ii) reusability [11], [22]. It provides a better support of how a system could restrain each of the quality objectives or the risk levels for evolution or how to reuse it [11]. It provides a framework of activities for architecture analysis process. This framework consists of gathering information about stakeholders, SA, quality, and scenarios, modeling usable artifacts, analysis, and evaluation activities [11]. ISARE: An Integrated Software Architecture Reuse and Evaluation Framework 177 Architecture Trade-Off Analysis Method (ATAM). ATAM is used to for architectural analysis of individual quality attributes. It wa

đang được dịch, vui lòng đợi..

Kết quả (Việt) 2:[Sao chép]

Sao chép!

2 Tổng quan tài liệu
Phần này thảo luận các điều khoản cơ bản, phương pháp SA và phân tích của họ hiện có.
2.1 Chất lượng thuộc tính (QA)
đặc điểm phi chức năng của một thành phần hoặc một hệ thống được gọi là thuộc tính chất lượng. Chất lượng phần mềm được định nghĩa trong IEEE 1061 là "mức độ mà các phần mềm sở hữu một sự kết hợp mong muốn của các thuộc tính" [4]. Nó là rất quan trọng để phân biệt giữa chất lượng phần mềm và chất lượng của SA. Chất lượng của phần mềm có nguồn gốc từ SA trong khi chất lượng của SA được yêu cầu một cách rõ ràng để đo được. Piattini et al. [5] kết luận rằng hầu hết các nghiên cứu đã tập trung vào chất lượng phần mềm nhưng có nhiều công trình nghiên cứu cần thiết về chất lượng của SA.
Kiến trúc 2.2 Phần mềm (SA)
Tất cả các hệ thống phần mềm đã SA mô tả các tổ chức cơ bản của hệ thống [4]. Thiết kế SA để đạt được bảo đảm chất lượng theo yêu cầu là một trong những nhiệm vụ đòi hỏi khắt khe nhất [7]. Các SA chụp quyết định thiết kế ban đầu và phản ánh mối quan tâm chất lượng chủ yếu, bao gồm chức năng [10]. Nó nhận ra yêu cầu chức năng của một hệ thống [8] và là một khía cạnh quan trọng của sản xuất các hệ thống phần mềm chất lượng cao [9]. Bass et al. [10] xác định SA của một hệ thống như là "cấu trúc hoặc cấu trúc của hệ thống, trong đó bao gồm các thành phần phần mềm, các thuộc tính bên ngoài nhìn thấy được của những thành phần, và các mối quan hệ giữa họ". SA phải đảm bảo mức chất lượng sẽ được chuyển giao cho người sử dụng, được gọi là QoS [8]. Ladan et al. [14] đề xuất qualitydriven quá trình phần mềm tái kỹ thuật để hỗ trợ QoS.
Kiến trúc 2.3 phần mềm với Tôn trọng QoS
Để xây dựng kết cấu kiến trúc phần mềm cho hệ thống đáp ứng các mong muốn của QA thường là một nhiệm vụ đầy thử thách. Ngoài yêu cầu chức năng, bảo đảm chất lượng cũng ảnh hưởng đến
176 R. Ahmad et al.
Sự lựa chọn thích hợp SA. Một kiến trúc phù hợp không chỉ được điều chỉnh bởi các yêu cầu chức năng nhưng, đến một mức độ lớn, bởi QA của [15], [16], [17]. Thường có nhiều hơn một QA tham gia vào một hệ thống và các kiến thức về những ưu và khuyết điểm của công trình kiến trúc khác nhau liên quan đến nhau QA với không đủ trưởng thành [15]. Trong [15] Svahnberg et al. đề xuất một phương pháp hỗ trợ quyết định cung cấp viện trợ trong việc tìm hiểu các cấu trúc kiến trúc khác nhau và lựa chọn kiến trúc thích hợp nhất để đáp ứng các yêu cầu chất lượng của hệ thống phần mềm từ một tập hợp các cấu trúc SA ứng cử viên. Phương pháp đề xuất cho phép một sự hiểu biết định lượng của các ứng cử viên kiến trúc khác nhau cho một hệ thống phần mềm. Các thiết lập của cấu trúc SA ứng cử viên và yêu cầu bảo đảm chất lượng của những nguyên liệu chính của quá trình. Kết quả của quá trình này là một cấu trúc SA thích hợp mà đáp ứng chỉ thị các yêu cầu bảo đảm chất lượng và sự không chắc chắn.
2.2 Tổng quan về các phương pháp phân tích
phần này cung cấp một cái nhìn tổng quan về các phương pháp SA hiện khác nhau. Kiến trúc Phương pháp Phân tích kịch bản dựa trên (SAAM). SAAM xuất hiện vào năm 1993 [19] với xu hướng cho một sự hiểu biết tốt hơn về các khái niệm kiến trúc chung, như một nền tảng để chứng minh rằng một hệ thống phần mềm đáp ứng nhiều hơn chỉ là chức năng yêu cầu [11], [18]. Mục đích của phương pháp này là để xác minh giả thuyết kiến trúc cơ bản và nguyên tắc đối với các tài liệu mô tả các đặc tính mong muốn của một ứng dụng [11]. Sức mạnh của phương pháp này là tập trung vào bất kỳ QA trong các hình thức của kịch bản. Các đầu vào chính của SAAM là mô tả vấn đề, yêu cầu tuyên bố và mô tả kiến trúc (s). SAAM Được thành lập vào kịch bản phức tạp (SAAMCS). SAAMCS là một phiên bản mở rộng của SAAM đó là hướng đến con đường tìm kiếm các kịch bản và, đến nơi mà ảnh hưởng của họ được đánh giá. Mục đích quan trọng của SAAMCS là đánh giá rủi ro. Nó cho rằng sự phức tạp của kịch bản là yếu tố quan trọng nhất để đánh giá rủi ro [11], [20]. Mở rộng SAAM Integration trong Domain (ESAAMI). ESAAMI là một sự kết hợp của khái niệm phân tích và tái sử dụng và đạt được bằng cách tích hợp các SAAM trong quá trình phát triển tên miền cụ thể và tái sử dụng dựa trên [11], [20]. Các SAAM là kỹ thuật đánh giá; các thuộc tính chất lượng và SA mô tả là như nhau trong cả hai SAAM và ESAAMI. Tuy nhiên, ESAAMI thêm việc tái sử dụng các kiến thức miền được quy định bởi các mẫu phân tích của SA và. Phần mềm Phương pháp Phân tích Kiến trúc cho Evolution và thể dùng lại (SAAMER). SAAMER là một phiên bản mở rộng của SAAM hỗ trợ hai đặc biệt QA. tức là, (i) sự tiến hóa, và (ii) có thể dùng lại [11], [22]. Nó cung cấp một hỗ trợ tốt hơn về cách thức một hệ thống có thể kiềm chế từng mục tiêu chất lượng, mức độ rủi ro cho sự tiến hóa hoặc làm thế nào để tái sử dụng nó [11]. Nó cung cấp một khuôn khổ các hoạt động cho quá trình phân tích kiến trúc. Khuôn khổ này bao gồm việc thu thập thông tin về các bên liên quan, SA, chất lượng, và kịch bản, mô hình hóa vật thể sử dụng, phân tích, và các hoạt động đánh giá [11].
ISARE: Một phần mềm tích hợp kiến trúc tái sử dụng và đánh giá khung 177
Kiến trúc thương mại-Off Phương pháp phân tích (ATAM). ATAM được sử dụng để phân tích kiến trúc của các thuộc tính chất lượng cá nhân. nó wa

đang được dịch, vui lòng đợi..

Kết quả (Việt) 3:[Sao chép]

Sao chép!

đang được dịch, vui lòng đợi..

Các ngôn ngữ khác

Hỗ trợ công cụ dịch thuật: Albania, Amharic, Anh, Armenia, Azerbaijan, Ba Lan, Ba Tư, Bantu, Basque, Belarus, Bengal, Bosnia, Bulgaria, Bồ Đào Nha, Catalan, Cebuano, Chichewa, Corsi, Creole (Haiti), Croatia, Do Thái, Estonia, Filipino, Frisia, Gael Scotland, Galicia, George, Gujarat, Hausa, Hawaii, Hindi, Hmong, Hungary, Hy Lạp, Hà Lan, Hà Lan (Nam Phi), Hàn, Iceland, Igbo, Ireland, Java, Kannada, Kazakh, Khmer, Kinyarwanda, Klingon, Kurd, Kyrgyz, Latinh, Latvia, Litva, Luxembourg, Lào, Macedonia, Malagasy, Malayalam, Malta, Maori, Marathi, Myanmar, Mã Lai, Mông Cổ, Na Uy, Nepal, Nga, Nhật, Odia (Oriya), Pashto, Pháp, Phát hiện ngôn ngữ, Phần Lan, Punjab, Quốc tế ngữ, Rumani, Samoa, Serbia, Sesotho, Shona, Sindhi, Sinhala, Slovak, Slovenia, Somali, Sunda, Swahili, Séc, Tajik, Tamil, Tatar, Telugu, Thái, Thổ Nhĩ Kỳ, Thụy Điển, Tiếng Indonesia, Tiếng Ý, Trung, Trung (Phồn thể), Turkmen, Tây Ban Nha, Ukraina, Urdu, Uyghur, Uzbek, Việt, Xứ Wales, Yiddish, Yoruba, Zulu, Đan Mạch, Đức, Ả Rập, dịch ngôn ngữ.