An Exemplary Approach For Efficient Software Architecture

Published Date: 02 Nov 2017

Abstract—Software Architecture during the designing process must comply with particular requirements, for the efficiency of the software. Further, the software architecture is analyzed in terms of performance, reliability, flexibility, adaptability, and security. This paper reviews some of the Software Architecture Analysis Methods (SAAM), methods to implement Fuzzy Association Rules (FAR) and a detailed analysis of Software Architecture in terms of performance, reliability, flexibility, adaptability, and security.

Index Terms—Adaptability index (Ai), Apriori Algorithm, Fuzzy Association Rule (FAR), non-functional requirements (NFRs), Software Architecture Analysis Methods (SAAM), Software Evolution, and Security Evaluation Framework (SEF).

Introduction

The software architecture analysis methods are evaluated in terms of many parameters and some of the major parameters are performance, reliability, flexibility, adaptability and security. Performance analysis has to achieve various goals, depending on the application of the development phase [49]. The most dependent parameters are reliability and performance. The reliability of the software architecture has been analyzed in various manners involving, subsystem interactions [19], fuzzy logic model [46], prediction models [39], and quality requirements [22]. Performance of the software architecture has been analyzed in various ways involving, distributed systems model [38], component-based analysis [45], multi-core platforms [41], Kieker Tool [37], and service-oriented architecture [2].

Related Work

Software Architecture Analysis for Enterprise Information Systems

Many software architecture proposals are accessible to industrial engineers in the development of enterprise information systems, but the systematic solutions for the assessment of software architecture are scarce [5]. Enterprise Information Systems (EIS) are the main IT assets for industrial organizations to plan, control and schedule their business process. EISs have become major enablers for the advanced enterprises to achieve effectiveness and streamline processes. An important component of EIS is software architecture. The software architecture of EIS comprises a group of system components and their topological relations. The architecture analysis depends on the early decisions about the high level design of software system.

Classification of NFRs: During the design and implementation of an EIS, the software architecture must support the principle business factor known as quality attributes or non-functional requirements (NFRs). During the selection of software architecture for an EIS, one needs to consider many and often conflict NFRs. For example, real time performance and a system’s flexibility are conflicted with each and must be balanced in software development. In a user-oriented technique, the key NFRs are estimated and the quality attribute scenarios are furnished to compute the degree to which the choices of the software architecture have influenced the satisfaction of the NFRs.

During the development of software architecture, the functional requirements define what the system can do and the non-functional requirements (NFRs) elaborate the adaptability of the system to satisfy the required functions. Some of the key NFRs for EISs are enlisted in TABLE I., along with their related concepts and topics.

Key NFRs For EISs

NFR

Related Concepts

Topics

Customer- Oriented

Intelligence

Customization

Flexibility

Aligning an organization’s business with customer’s needs

Performance

Efficiency

Schedulability

Real-time

Memory Usage

Optimization of system performance under many conditions

Agility

Adaptability

Autonomy

Flexibility

Rapid response to variations and uncertainties

Reliability

Robustness

Fault Handling

Accountancy

Control a system to resistance or product failures

Security

Information Protection

Safety

Free from malicious threats

The NFRs such as reliability and security are software-driven, whereas NFRS such as flexibility, performance and adaptability are business-driven.

Classification of Software Architecture: The software architecture the external properties of the components in a system and the internal relations between them. In terms of industrial informatics, software architecture defines the processes and business structures of an EIS.

An important aspect in the software architecture development is the patterns codification which is used as the blueprint of constraints, components, and their relations. Patterns develop the general the solutions that can be used again to fasten the software development. Some techniques employ the operational patterns for the EIS design as follows.

General Purpose Software Packages: This technique encapsulates the algorithms and data structures to implement a general and customizable solution of the business requirements. Some of the packages used are database-centered data sharing, event driven message invocation and pipeline-based data processing.

Domain-specific software architecture: It focusses on a specific domain and has special components. Some of the examples are Enterprise Java Beans (EJB), business component factory and Microsoft’s Component Object Model (COM+).

Distributed Computing involves many elements interacting and coordinating to achieve a goal. Some of the architectural options are client-server, peer-to-peer and n-tier architecture.

Agent and Multi-agent Systems (MAS): An agent is an independent element in the environment; whereas MAS consists of a set of agents. The agents inside the MAS can coordinate with each other to attain the goals at the system level.

Service-oriented Architecture (SoA): It is the recent type of software architecture. It combines heterogeneous platforms and allows an EIS to enlarge its capabilities by employing reusable software modules.

A Threat-model Based Security Testing for Software Architecture

Some of the issues in the cyberspace community are denial-of-service attacks, corruption of data and disclosure of confidential information [7]. Some of the issues affecting the software security are cross-site scripting (XSS) or SQL injection. Threat modeling is useful in both software testing phase and software design and development phases.

Threat modeling is a systematic way to detect threats that might bypass the security. The test case generation from the threat models has not been focused much, so a threat model-based security testing is proposed, which automatically produces test sequences from threat trees and converts them into executable tests.

The threat model examines the application in the view of a potential attacker and aids them estimate the potential security risks. The main functions of threat model are identification of the application’s assets, determination of the threats to an application, ranking the threats and palliation of threats.

Threat modeling involves the identification, specification, evaluation and counter-measurements against potential security attacks. The threat modeling can be performed at different levels of abstraction and granularity. Some of the notations used in threat modeling are threat trees, threat nets, and misuse cases. Threat nets are built upon Petri nets, a mathematically based principle for modeling and checking distributed systems. Misuse case modeling defines misuse cases as threats to use cases and prefers mitigation use cases.

Mutation analysis is a technique which produces mutants by injecting threats deliberately and estimates how many of the injected threats can be revealed by security tests. There are three types of mutation analysis; they are implementation-level security mutation, mutation of access control policies and specification-level security mutation. In implementation-level security mutation the vulnerabilities are injected into the implementation and the number of vulnerabilities that can be revealed by the security tests is evaluated. Specification-level security mutation introduces errors in the description of the security-related behaviors so as to produce threat scenarios. In mutation analysis of access control policies, there are two important systems to create access and control policies. The first system uses role-based access control (RBAC) or organization-based access control. The second system uses eXtensible Access Control Markup Language (XACML) to produce the original implementation of a security scheme. During the transformation of the test sequences to the executable test codes, the feasible input data must be considered carefully.

Detection of Software Security Patterns

The use of security patterns improves the software security in the early software development stages [51]. The security patterns in the code are detected by a reverse engineering tool-suite known as Bauhaus. This approach detects the Single Access Point security pattern. The recent security tools support the developers during the implementation phase depending on the static analysis.

The software has to be altered frequently due to the varying constraints, bugs and security defects. Also, the reconstruction of patterns in developed systems is tedious. Security patterns should be acknowledged during the maintenance process to ensure security objectives. A Resource Flow Graph (RFG) representation is used by the Bauhaus tool-suite. This method reconstructs the software architecture by a hypothetical architecture to the actual software architecture obtained from the source code.

Software Architecture Adaptability Based on QoS Self-Adaption

The software systems should be able to adapt themselves to the environment dynamically to meet both the functional and non-functional requirements [42]. The functional requirements focus on the overall implementation logic and the non-functional requirements focus on the QoS levels to be ensured.

Adaptability has an effect over other software qualities such as performance, maintainability or reliability. Also in the worst case, the improvement of adaptability could lessen other qualities of the system. So, an efficient trade-off must be maintained between the system adaptability and another quality of the system. These adaptability metrics support a higher degree of quantification from the basic metric. The metrics are also quantified besides the tracking.

Construction and Exploitation of Flexibility in Software Architecture

Flexibility can be attained by aspect-orientation. It is a mechanism which focuses on the design-time separation of the cross-cutting system features which are embedded into the system [18]. This orientation permits an additional dimension of decomposition and strongly localized changes. Software Product Lines is a mechanism for systematic usage of commonalities among software products. This is attained by systematically reusing the common divisions of the systems. The commonalities and variations among the products are analyzed.

Software Architecture Analysis Method (SAAM) and Architecture Trade-off Analysis Method (ATAM) generally focus on quality attributes, and Architecture-Level Modifiability Analysis (ALMA) focus on maintainability. ArchE design assistant permits the monitoring of modifiability during the time of designing, but with particular support on selection of architectural techniques.

An Adaptive Software Architecture for Multi-Core Platforms

This analysis method focuses on the performance parameters for an adaptive software architecture, which has many levels of fault detection, recovery and masking through reconfiguration of the architecture [41]. The architecture is initialized with a formal requirement model denoting the multiple levels of information assurance and functional capability. The architecture encompasses a multi-layer design to apply the constraints using N-variant techniques. The architecture also integrates a reconfiguration scheme that utilizes the lower layer to assess the higher layers. When a fault is detected the reconfiguration scheme reconfigures the system to maintain the required services.

A general reliability model is provided with cross-surveillance for reconfiguration, based on the generalized stochastic Petri nets. Then, a probabilistic automation-based behavioral model is defined. This model is appropriate for modeling the problems in security by value faults. Petri net permits the reliability modeling and reconfiguration and the performance analysis is given by the probabilistic model checking. The goal of this analysis is to capture the computational power of the under-utilized cores for enhancing the survivability and adaptability of critical applications. The layered architecture provides on-the-fly reconfiguration.

Software Lifecycle

A software process is a group of activities that are integrated to produce a software system [50]. There are some common stages that can be seen in every software process, where each stage consists of a set of well-defined functions. These stages identify different abstractions of the software under development.

Requirement Specification concentrates on the functionalities of the system and on their operational limitations. Software design and implementation discusses about the creation of the software system according to its requirements. Software verification and validation is a level which proves that the software system conforms to the limitations in the specification stage. Software evolution is a period when the changes in the software architecture occur. The waterfall process model organizes and explains the lifecycle stages as shown in Fig. 1.

Waterfall Process Model.

Another software process model is the iterative process model, which deals with the specification, application and validation functions concurrently in order to rapidly create an initial edition of the software system, that can be later refined through iterations as shown in Fig. 2.

Reliability Evaluation of Software Architecture under Uncertainty

The accuracy of a reliability computation in the software architecture depends on the number of factor that requires to be estimated, such as usage of system [43]. The earlier approaches have assumed that the input factors are normally distributed, and that it is adequate to report the qualities that describe the system in terms of variance and average of the quality. A simulation-based method is proposed to facilitate a broad group of parameter range distributions. This technique self-regulates the number of architecture computations to the desired level and informs the required percentiles of the values which finally characterize a specific character of the system. The probabilistic parameters and their computations have been analyzed by a Monte Carlo (MC) simulation. A nonparametric significance analysis such as a stopping condition has considerably decreased the quantity of trail runs and function computations required to achieve the desired confidence level.

Iterative Process Model.

Decision-Making in Software Architecture Design

The software architecture of an intensive system can be defined as the group of relevant design decisions that has an impact on the qualities of the system [48]. Software engineering involves the selection of several software architectural alternatives, but there is no definite guidance on which architecture is most suitable in terms of tradeoffs. A general of the software architecture design process is given in Fig. 3.

Software Architecture Design Process.

Integrative Software Architecture for Reliability

Reliability in Software Architecture has impact both on the cost of field operation and the experience of the users [36]. A major challenge in the software architecture design process is the accurate prediction and improvement of the software reliability in terms of factors such as outage frequency and duration before software delivery. An integrative software reliability structure is framed to fulfill the emptiness between predictions, expectations, and the real behavior of systems. An integrative algorithm implementing the design for reliability (DfR) in software architectures is given in Fig. 4. And the general scheme for software reliability prediction is given in Fig. 5.

Integrative Design for Reliability.

Measurement of Software Architecture Reliability by a Fuzzy Model

Several models have been proposed for predicting the quality attributes of the software architecture [44]. This technique involves a Fuzzy model for the prediction of software reliability. Some of the parameters considered for the prediction analysis are Availability, Recoverability and Failure Probability. The Fuzzy Model aids to evolve the intermediate levels between the reliable and unreliable states of the software architecture.

Prediction of Reliability in Fault-Tolerant Software Architectures

The software fault tolerance schemes improve the reliability of the software architectures [52]. A new approach is proposed for the analysis of the effect of software tolerance scheme on multiple and differing software architectures. This approach models the various alternatives of the software architecture and configurations of the product line from a shared core property. This mechanism provides flexibility to various fault tolerant schemes. The models are transformed into Markov chains by a tool and the system (software and hardware) reliabilities are computed. This provides a validation process for the software architects during the early development stages.

Overview of Software Reliability Prediction.

Software Architecture Analysis

Some of the methods for the software architecture analysis with respect to evaluation perspectives are discussed in this section.

Security Analysis of Software Architecture Based on Analytical Hierarchy Process (AHP)

The evaluation of the software security at an early stage is important, as it guarantees the stakeholder’s security objectives [53]. A robust security evaluation method to estimate the security support of software architecture in the design phase is developed and is known as Security Evaluation Framework (SEF). The SEF also has some limitations such as the security evaluation considers only the architectural level and not the scenarios on the structural components. A hybrid software security risk evaluation model based on Analytical Hierarchy Process (AHP) is proposed. The SEF consists of six steps [53] as described in Fig. 6.

The initial constituent of the process is the evaluation of a scenario-based architecture. The evaluation of the software architecture is a competent way of guaranteeing design quality. The architecture’s ability to render a system that satisfies the stakeholders’ quality requirements to detect the potential risks. The involvement of the security patterns increases the quality of the security constituents in the architecture.

Security Evaluation Framework (SEF).

The Analytical Hierarchy Process (AHP) is a decision making technique used in a multivariable decision problem. The construction of the hierarchy is performed so that the elements at similar level are of the same order of magnitude and must be associated to some or all elements in the next upper level. After the hierarchy construction, the prioritization process determines the relative importance of the constituents in each level of the hierarchy. The AHP employs a pair-wise comparison matrix to compute the relative objective weight of factors. The components in each level are pair-wise compared relative to their importance in deciding under consideration. A pair-wise comparison matrix is constructed to compute the relative importance between factors of the decision elements.

Software Architecture Adaptability Based on QoS Self-Adaption

The design of the systems in Software Engineering must be able to adapt to quick alterations of their requirements and evolve overtime [42]. The quantification and evaluation of metrics such as software adaptability are defined. The quality of service (QoS) must be ensured by the values of these metrics. These metrics are used by the software architect to assist the system adaptation to satisfy the overall quality requirements.

Quantification of the Software Architecture’s Adaptability: The adaptability metrics of the software architecture are based on the system’s architectural knowledge; hence, adaptability can be computed before the software designing process.

A system of n different functionalities, fi | i= {1 ... n}, and existence of n sets, SUi are assumed. Each SUi consists of software units offering the functionality. For each fi, an architect can select a subset (Ei) of the existences, where E­i is the software units considered. Thus, the system adapts its behavior in |Ei| ways for each fi. Some of the adaptability metrics used for the software architecture is given as follows:

Absolute Functionality Adaptability Index (AFAI) defines the number of software units it uses for a given functionality.

Relative Functionality Adaptability Index (RFAI) defines the number of software units it uses with respect to the units actually offering needed functionality. This adaptability index (Ai) communicates with the architect about the adaptability of the functionality. When the RFAI vector values are near unity means that the system is using most of the adaptability which can be offered.

Absolute Software Units Index (ASUI) defines the total number of software units used by the system. This adaptability index provides a global view of the system size and an overview on the attempt needed to manage the whole software architecture.

Mean Functionality Adaptability Index (MFAI) defines the mean number of software units utilized per functionality. This metric gives an overview on the mean size and the steps to manage the functionalities.

Mean of Relative Functionality Adaptability Index (MRSAI) defines the mean of the number of software units utilized for the functionalities relative to the number of units that could be used. It also explains how the functionalities concentrate their adaptability choices in average. This index communicates with the architects about the mean extent of utilization of the potential units for the functionalities. A value close to unity denotes that the present architecture uses almost all the software units available. And a value close to zero denotes that the system can be more adaptable and different architecture alternatives of the same adaptability metric could be created.

Absolute System Adaptability Index (ASAI) defines the number of software units utilized by the system relative to number of available software units for the construction of the system. A value close to unity denotes that there are only few choices available to increase the system adaptability. With respect to MRSAI, this adaptability metric encompasses a global view of the system size relative to its maximum attainable size, but does not forecast the amount of different architectural options the system could attain.

Adaptability and Quality Requirement: The requirements are for the software architecture are focused and classified as presented in TABLE II.

Adaptability’s Behavior Relative To A Quality Requirement

As adaptability increases

Requirement formulated as

Higher than

Lower than

Increase of quality value

Helps

Hurts

Decrease of quality value

Hurts

Helps

Quality value not affected

No effect

The first dimension of TABLE II, distinguishes the software qualities into three categories:

Qualities that increase their value when adaptability is increased.

Qualities that decrease their value when adaptability is increased.

Qualities that do not rely on adaptability variations.

The second dimension in TABLE II defines how the requirement is computed in terms of the variations in intensity as higher or lower. The labels Helps and Hurts are given in TABLE II to obtain the effect of adaptability on quality requirements.

Fig. 7 and Fig. 8, gives general graph for quality requirements that belongs the first Helps, i.e. the quality value which increases when there is an increase in adaptability and are computed as higher than. X-axis denotes increasing values of the applicable adaptability metric (Ai). Y-axis denotes the values for the target quality; AdaptMax is the maximum adaptability value which can be considered by the architect. When the adaptability metric is not explicitly given, then a combination of all the adaptability metrics is considered. The upper bound (VAiU) and the lower bound (VAiL) on the quality the architecture with adaptability Ai can be reached is estimated.

Quality in Helps where the requirement is higher than.

Quality in Hurts where the requirement is lower than.

In Fig. 7, the requirement to satisfy is called Quality Requirement value. Adapt- is the lowest Ai which can fulfill the requirement, and Adapt+ denotes the lowest Ai whose lower bound also fulfills the requirement, which indeed is fulfilled until AdaptMax. These values satisfy the requirements: the system should have at least adaptability Adapt-, and, any selected architecture with at least Adapt+ adaptability value will also satisfy it. For intermediate adaptabilities, there will be architectural choices that will fulfill the requirement and others that will not fulfill the requirements.

Fig. 8 shows the graph for requirements belonging to Hurts whose quality value increases with adaptability and are computed as lower than. Adapt- refers to the maximum Ai for whatever architectural option, with such value, for sure fulfills the constraint, and Adapt+ refers to the maximum Ai for which options that fulfill the requirement.

The evaluation of a given constraint or, more general, the (adaptability vs. property) trade-off study implies to produce the graph for the system under observation. Starting with Ai = A0, VA0U, VA0L are computed. Next, the adaptability value is increased and considered the next lowest value Ai = A1 and its VA1U and VA1L are computed. The process goes until Ai reaches AdaptMax. These results produce the actual upper and lower bound curves. Depending on where the target quality belongs, the variable Adapt- is considered as the lowest Ai that can fulfill the requirement or the highest Ai where both VAiU and VAiL fulfill the requirement. Similarly, to compute Adapt+, quality is checked whether it belongs to Helps the lowest Ai where both VAiU and VAiL bounds fulfill the constraints, or belonging to Hurts the highest Ai that can fulfill the requirement.

Practically in the calculation of the bounds for a given Ai (i.e., VAiU and VAiL), avoid taking into consideration the non-suitable architectural options. This refers that a software unit offering functionality fj should not be considered in architecture unless another software unit requiring fj had already been considered.

Construction and Exploitation of Flexibility in Software Architecture

Flexibility in the software architecture is considered during system evolution [18]. An automated flexibility analysis is designed with real-time feedback. A flexibility exploitation analysis is implemented for the purpose of software evolution. This constructs the design time analysis and results in effective utilization of the given flexibility by forming flexibility-aware function-plans. Flexibility is the main attribute that defines the easiness, cost and speed in which the required changes to the software systems could be conducted. A modeling and analysis approach is proposed for the construction and application of flexibility throughout the life-cycle in order to increase systematic support for flexibility.

Flexibility is about the response to the future variations of the software. Flexibility is a group of expected potential variations, similar to modifiability. Flexibility scenarios are conditions which define the constraints about the potential changes to the system. The realization of the flexibility scenarios prepares the system for the changes at a later point in time with less effort.

The software architecture estimates with its key design conclusions how much changes are required at the implementation level. The architect has the responsibility to lead design decisions, thereby providing flexibility. The system is modularized in a manner that a specific modification depicted in a flexibility scenario can be performed with minimal local impact alone.

One way to build flexibility is by introduction of metadata, which means that specific alterations can be performed in configuration files. Thus, the recompilation in the source code is not required and modifications do not involve programming knowledge.

Overview of Flexibility Enhancement: During the construction of a software system, flexibility is built into the system. There can be variations in the system during evolution, which increases the present flexibility. Fig. 9 shows the construction and exploitation of flexibility. For the construction of flexibility, the scenarios act as the input to the architecture design. While designing the architecture, an automated feedback is provided about the present degree of flexibility in an architecture modeling tool.

Construction and Exploitation of Flexibility.

A tool-based support for derivation of work plans and analysis of change impacts is provided. Exploiting the flexibility is a development process, which is activated by a strong change request. The exploitation process can be used for rapid identification of the areas of a system which are affected by the saving effort for flexibility exploitation and change request.

Construction of Flexibility: Generally there are two approaches for the optimization of flexibility. First, the architect can be guide to choose more appropriate decisions. Second, the architect can be supported in recognition of sufficient or insufficient architectural decisions, by the measurement of the attained level of characteristics. Practically, architecture design deals with large-scale systems, which makes the impact change analysis manually, a tedious process. Also, additional complexity is established for the architecture model.

The automated analysis of a modeled software architecture relative flexibility and its scenario is not easy. So, a new architectural view known as Change Impact View is introduced. Here, the flexibility scenarios are the initial-class modeling entities. Also, an explicit Impacts-relationship is introduced between flexibility scenarios and architectural entities. The architect models the impact of each scenario on every impacted entity by adding these details as numbers. During the initial phase of the system design, the architects can come up only with rough estimates of element sizes. A link of the architecture model with the size metrics of the implementation is possible when an implementation already exists.

For the automated flexibility analysis, a comparable and computable metric of flexibility is required. The impact analysis for every change on an element is estimated. Also, the architecture element’s code size is estimated roughly. The flexibility metric is defined according to the function shown in Fig. 10, where ‘LoC’ refers to the Lines of Code executed. The flexibility of software architecture is defined in the time period [0, 1], where ‘1’ refers for high flexibility and ‘0’ refers low flexibility. The flexibility is unity when the change due to a scenario impacts less than 10 lines of codes. This limit refers a minimal change impact to the present system. Similarly, the flexibility is zero when the change impacts more than 10 lines of code. This limit refers a considerable division of the system which has to be modified to account for the change requirements. The intermediate values of the function are linear. The boundary limits are estimated from the practical experiences and can also be altered by the architect.

Flexibility Metric.

The automated analysis algorithm can execute the architecture model in near real-time and provide direct feedback to the architect, based on the flexibility-specific enhancements of the architecture model. This flexibility metric can aggregate the flexibility values for multiple scenarios and system parts. The computation of the aggregated flexibility scenarios can be performed by weighing the scenarios so that it does not strongly impact the flexibility results. Accurate flexibility analysis results can be obtained by regarding the persistent and explicit considerations in the architecture model. When a change request is received similar to an already regarded flexibility scenario, the change impact view is utilized to identify how the variation is accounted and it can yield a rough computation of the effort to be spent.

Realization of Changes: The flexibility is established by incorporation of flexibility mechanisms and consideration of flexibility scenarios. During the software evolution, major change requests are needed. Now the provided flexibility has to be exploited. The original modifications of the system relative to the change request have to be organized and planned in a manner that the present flexibility schemes are employed during the implementation.

Flexibility Exploitation Analysis is a semi-automated analysis based on the results in work plans which address the present flexibility explicitly during the architecture construction. The architects apply the change requests to the model of the software architecture and derive the work functions from the modifications of the model, i.e. the architecture model is altered to denote the target system state for a change request, differences to the earlier software architecture is computed and it is translated into work activities.

Design time approach involves the modeling of flexibility scenario at least for the explicit flexibility schemes in a change impact view. When a change request similar to a modeled flexibility scenario occurs in the change impact view, the architects can alter the software architecture model as suggested by the change impact view. The derived work functions can be denoted in terms of flexibility scheme roles that are affected. The implementation of the changes often leads to work functions from various fields of functions. So, besides the implementation functions other fields of functions during the work planning are also considered.

Preparation of Input Software Architecture Model: The software architecture model acts as the primary input for the analysis. For this input, the architects can reuse the architecture model from the design phase. The architecture model is enriched in following steps. First, the architects should guarantee that all known flexibility schemes are documented explicitly. This is done by annotating the components with role names of flexibility patterns or styles. Second, the architects utilize the following model annotations to show other fields of activities.

All the components are specified by the physical representation of configuration (meta-data) files and source files.

All the components are annotated with the number of test cases.

All the components are specified with the number of deployment nodes and the multiplicities in the deployment model.

This information is furnished only once and then it can be applied for any number of change request analysis.

Extension of Change Requests: A copy is created for every change request. The architects apply the changes to the architecture model so that it contemplates the desired system state after the implementation of the change request. Changes which do not alter the structure of the component structure but only the internal components are highlighted in the architecture model with internal alteration annotations.

The manner in which the change request should be applied in the architecture should be decided. The creative decisions involve decisions which cannot be entirely automated by the tool-support.

Computation of Difference and Derivation of Work Plans: The analysis tool calculates the variations between the base edition and target editions of the software architecture model and converts them into workplan activities.

Some of the alterations mapped to the activities with respect to specific features are:

Component repository: Add, Remove, Modify Component; Add, Remove, Modify Interface Port

System structure: Add, Remove, Update Component Instance

Component deployment: Increase, Decrease the count of Deployment Nodes for all Component Instances

Flexibility Roles: Add, Delete a Role to or from Component

The following work activities are derived from the additional model information:

When a component is added or altered and there is annotation of the source code representation, results in coding activity.

The alterations to the parts with a meta-data representation will result in configuration activity.

Coding activity will end up in accumulative build activity.

Coding and Configuration activities will result in accumulative deployment activities.

Test case annotations to various parts will lead to accumulative test execution activities.

Fuzzy Association Rule

Various methods to implement the fuzzy association rule have been proposed. FAR is usually applied in databases and statistics. Some of the applications of FAR are in pattern deduction on geo-referenced crime [13], EC (Electronic Commerce) environments [33], and stock markets [3]. The FAR is implemented in various mechanisms involving, Multi-level FAR based on Cumulative Distributive Function [25], Quantitative algorithm for generic extraction of FAR [14], multi-level FAR for membership functions [26], and multi-class fuzzy classifiers [32].

Fuzzy Transforms to Detect the Fuzzy Association Rules

Fuzzy transforms are used for the detection of coarse-grained fuzzy association rules (FAR) in the datasets [31]. The FAR are denoted in the means of linguistic expressions. A pre-processing phase evaluates the optimal fuzzy division of the domains of the quantitative features. During the extraction of the FAR, a confidence index (con) and the AprioriGen algorithm is utilized to compute the inverse fuzzy transform. This technique is also used in data mining process, where a detailed analysis of the FAR is not necessary.

The extraction process of the fuzzy association rules is shown in Fig. 11. The extraction process involves two sub-processes. The AprioriGen algorithm is used for the selection of user FAR and for selecting the predecessors with maximum dimension and support greater than or equal to the threshold supε. The AprioriGen algorithm involves two steps: Join step and Pruning step. The join step involves the production and formation of an itemset by ‘k’ attributes. This is performed by combining two (k-1) attribute having similar first (k-2) attributes. The pruning step involves the removal of all the entities that do not contain all the first (k-1) subsets. The second sub-process involves the extraction of the FAR if the grade of confidence (con) is greater than or equal to the threshold conε.

Extraction of Fuzzy Association Rules.

In Fig. 11, X1 … Xk is the group of datasets collected. X­1 is denoted as A1, h1 and Xk is denoted as Ak, hk. Xz = H (X1 … Xk), where H is a function estimated through a suitable fuzzy partition of the individual attribute domains. The average of Xz is denoted as א.

Enhanced Fuzzy Association Rule

A fuzzy Associative Rule Mining (ARM) algorithm known as FFI_Stream is proposed to deal with statistical values in data streams [15]. Real datasets and synthetic datasets are used for the performance analysis of the system. When compared to discrete methods, this technique establishes a trade-off between the numbers of fuzzy associative rules and the efficiency of the system. A time based sliding window model is used for the estimation of the fuzzy association rules in the given input and the clustering technique is used to compute the fuzzy sets.

Fuzzy Association Rule in Financial Data Association

The investment profitability is enhanced by the fuzzy association rules and a decision support system [27]. The investors could cognize the association among the different parameters. After the extraction of the associations, the investors can implement the rules in their decision support systems.

Temporal Fuzzy Association Rule With 2-tuple Linguistic Expression

Fuzzy association rules that have temporal patterns are dealt by the 2-tuple linguistic expression [20]. This method identifies the FAR in a temporal manner while conserving the interpretability of linguistic variables. Iterative Rule Learning (IRL) combined with a Genetic Algorithm (GA) implements the rules and shapes the membership functions. The rules found are differentiated with those from a classical method of finding the FAR.

Unsigned Fuzzy Association Rules With Minimum Supports

Classical algorithms for mining the association rules are constructed on the binary factors of the databases. This has three demerits. First, the algorithm can focus on quantitative attributes. Second, only positive FAR are found in the mining. Third, the algorithm treats every item with similar frequency although various items may have various frequencies [10]. A discovery algorithm is proposed for mining unsigned fuzzy association rules.

Fuzzy Association Rules Using Genetic Algorithm and 2-tuple Linguistic Expressions

A multi-objective genetic algorithm is proposed for detecting the FAR without any specifications of the minimum confidence and support [28]. This technique involves the extraction of both membership functions and FAR in a single step. Iterative Rule Learning (IRL) is used to cover the uncovered instances.

Fuzzy Association Rules in Low-Quality Data

A data-mining algorithm is proposed to obtain the useful information from the databases with imprecise data [17]. This technique combines the fuzzy apriori algorithm and imprecise data concepts to deduce the useful fuzzy association rules in the given databases.

Axiomatic Fuzzy Set Association Rules

Fuzzy Set Association Rules are proposed for classification issues such as, AFS (Axiomatic Fuzzy Set) theory and AFSRC (AFS association rules for classification) [12]. It is a simple and efficient mechanism which retains the significant rules for classes which are imbalanced. This is performed by fuzzifying class support of a rule. A new model creates the membership functions automatically by executing the available data.

Follow-Up Mamdani Fuzzy Modeling

Fuzzy logic has exploited for the interpretation of human derived control rules [29]. The linguistic fuzzy rules are used to represent the data in classification and association rule mining. Fuzzy Rules Based Systems (FRBS) are applied in data mining for classification of datasets which are imbalanced.

Fuzzy Association Rules for Discovering Threats to Privacy

This technique focuses on the preservation of privacy in databases through fuzzy rules. The fuzzy rules are based on a decision tree [40]. The predecessor of each created by these systems comprise the details about the released variables (quasi-identifier), whereas the accompanying comprises the data only about the protected variable.

Multi-Level Association Rules for Quantitative Data

Data-mining involves the translation of data into useful and organized information [23]. A multi-level fuzzy association rule model is proposed for the extraction of general information stored as quantitative values during transfers. This method uses various support value at each level and various membership functions for every item. The derivation of large itemsets involves a top-down progressively deepening scheme. Also fuzzy boundaries are utilized instead of the conventional sharp boundary intervals.

Fuzzy Association Rules Based on Equivalence Redundancy of Items

The computational time of the mining process is improved and the extracted repetitive rules are pruned in this method [11]. The equivalence redundancy of the fuzzy itemsets and related theorems are defined. A basic algorithm based on Apriori algorithm is proposed for the extraction of the rules using the equivalence redundancy of fuzzy itemsets.

Fuzzy Association Rule Based Extraction of Frequent Patterns

Frequent itemset is usually located in large transactional databases [16]. A new method for the estimation of the frequent patterns is proposed for the uncertain data. The fuzzy concept is utilized the detection of the frequent patterns. This method can produce large frequent itemsets and then estimate the FAR from the uncertain dataset. The advantage of this technique is that the dataset scanning is performed only once.

Background Work

Software Architecture for Online Services

The web-services are increasing drastically, with their functions and memory consumption. Efficient software architecture is proposed for web-services like social networking, search and geo-location services [4]. Social networks like Twitter have risen as an efficient open social network among all communities. A spatial and semantic analysis of the social network data is analyzed. A functional diversity approach is proposed to enhance the fault tolerance for the data collection, where its performance is evaluated. This software architecture enables the spatial patterns inside the geo-locations and can give the user with resourceful unpredictable elements.

The software system is able to collect a huge amount of geo-located Twitter data online and provide different search functionalities on the database. The architecture is constructed on the assumption that the real time condition is reduced which allows more advanced semantic analysis. The software architecture is built on Python-based web framework Django. The software system is combined with Apache Lucene / Solr system. The architecture comprises a highly efficient inverted index representation. The semantic aspect of the search needs to be considered carefully by the following strategy. First, an adaptable Slang database is combined into the original system which permits the system to replace correct English phrases to the detected slangs in tweets. Second, a semantic similarity based short path and a wordnet lexical database is used to expand the actual query to synonyms, hypernyms and hyponyms of every query word. Finally, by employing advanced Lucene’s query handling, phrase and word based queries with different logical conditions are enabled efficiently. A fault tolerant system is implemented by using individual machines simultaneously for collection and then merging the databases.

Software Architecture Evolution

Software evolvability is the software system’s capability to change to future events [35]. This results in better economic value of the software. For long-term systems, evolvability is required explicitly during the whole software lifecycle to have a good productive lifetime of software systems.

The software lifecycle studies can be based on five sub-categories:

Quality Considerations during Design: The approaches for the assessment of the software lifecycle can be based on conditions like quality attribute focused on requirement, influencing factor and scenario.

Evaluation of Architectural Quality: The approaches for the evaluation of the architectural quality can be experience-based, metric-based and scenario-based.

Economic Valuation: These approaches enlarge the information on architectural conclusions’ business consequences, and aid development teams in selecting among architectural options.

Architectural Knowledge Management: These approaches enhance the architectural integrity by improving architecture documentation by the extraction of architectural knowledge from different information sources.

Models for Software Evolution: These techniques function as modeling software artifacts providing traceability and visualization of the impact of software architecture artifacts’ evolution.

Software Architecture Analysis for Large-Scale Distributed Systems

Large-scale distributed systems involve substantial investment and high risk [1]. Some of the former architectural decisions describe how the system is organized in terms of permanent data communication, coarse-grained modularization, data management, data I/O and allocation. Such an organization’s "back-bone" is known as System Organization Pattern. Analysis of the software architecture early in the development cycle identifies the significant technical risks and avoids them at minimal cost. But, architecture analysis methods such as the Architecture Trade-off Analysis Method (ATAM) cannot be applied very early for conceptually designed architecture, as the influence of System Organization Pattern on the minute details of the final system cannot be accurately defined. So, the Early Architecture Evaluation Method (EAEM) is developed to estimate the System Organization Pattern before an ATAM-based estimation would be feasible. The architecture evaluation works upon the Goal-Question-Metric scheme. It recognizes the substantial risks faced by the architectural decisions involving the System Organization Pattern. The EAEM depends on the existing quality scenario-directed architecture analysis methods.

Concern-based Software Architecture for Groupware Systems

This software architecture analysis involves collaboration and interaction analysis, which permits the study and characterization of the collaborative functions by the groupware system users [30]. The automation of the collaboration and interaction analysis endows the assessment of the users’ work and improvement of groupware system behavior and support. A concern-based architecture is proposed for the groupware developers as a model to the integration of analysis subsystems into groupware systems. The whole groupware system can be represented by a group of subsystems (Meta-information, Analysis, Identification, Application and Awareness). The subsystems communicate with each other to substantiate the basic functions and analyze the collaborative work of the users. The basic functions are user management and support for collaborative functions within the shared workspaces. This architecture is designed for the COLLECE groupware system, which sustains the collaborative programming principles.

Combining Software Architecture with Team Structure in Open Source Software Development

The integration of the developer team structure and open source software (OSS) architecture monitors the socio-technical interactions in a system development [6]. A high level of structural interdependency combined with larger teams result in better project performance.

Session Reliability Analysis of Web Systems Under Heavy-tailed Workloads

A framework for modeling the session reliability has been proposed by integration of user view and system view [8]. The user view is defined by the session layer, whereas the system view is defined by the service layer. The session layer can handle heavy tailed workloads which exist in real Web systems. The service layer concentrates on the observed request reliability from the service provider’s view. Multi-web server architecture and the manner in which the components interact to service the requests are considered. The reliability of the requests are estimated by cognizing the individual components’ reliabilities. The manner in which the components interact with each other is defined by the software architecture.

Enhancing Software Adaptability through Reflection Programming

The development of software is analyzed from the programming aspect and it is deemed that it is the period of adaptive programming at present [9]. Reflex technology for enhancing the software adaptability. The self-reflection and meditation a principle for encoding the execution state as code known as reification. The reflection programming enables the automatic execution of the software through self-reflection.

Variability Analysis in Software Architecture

Variability is an important parameter in the context of software architecture [47]. Besides the idea of product lines, the issue of variability in the software domain is examined. In this survey, a study is conducted among various subjects in terms of variability. It is observed that there is no common apprehension of "variability" in the view of software architecture. It is also noted that some challenges in the variability of the software architecture also exists in the product line domain. Some of the challenges with variability in the software architecture are complexity, formality and management.

Improving the Deployment Architecture of Software in Distributed Systems

The allocation of the software components to the respective hardware nodes has a significant impact on the QoS of distributed software systems (DSS) [21]. For a specified system, the deployment architectures provide the same functionalities but different QoS levels. The parameters which influence the deployment architecture’s quality are often not cognized before the system’s initial deployment and may alter at runtime. This necessitates the redeployment of the software to enhance the QoS of the system. A framework is evaluated at determining the most suitable deployment architecture for a DSS relative to multiple confusing QoS dimensions. The framework bolsters a formal modeling and a group of adaptable algorithms for enhancing the system’s deployment.

A Deployment Improvement Framework (DIF) is proposed to enhance the software-intensive system’s QoS by determining the appropriate deployment of the system’s software parts onto its hardware hosts. DIF permits quick, quantitative exploration of a system’s deployment space. The framework model’s design and the algorithms permit the random specification of new QoS dimensions and their enhancements. The data about the system parameters are either obtained at design-time or at run-time and an enhanced deployment architecture is computed and applied.

Reliability Oriented Software Evolution Based on Contribution Degree of Component

The reliability of the software architecture is enhanced by analysis contribution degree of component [24]. The various components of the system serve various roles in the reliability-oriented software architecture evolution. The reliability-oriented evolution technique upon the contribution degree of component is employed in an ATM system.

Fuzzy Rules for Time-Series Data

Time series analysis is used frequently in various applications [34]. Several data mining techniques have concentrated only on binary-valued data, but time series data are quantitative values. A fuzzy mining scheme is proposed to estimate the linguistic association rules. This method uses a sliding window to produce continuous subsequences from a specified time series. The fuzzy itemsets are analyzed from the subsequences and relevant post-processing is performed to exclude the repetitive patterns.

Discussion And Results

Security Analysis of Software Architecture Based on Analytical Hierarchy Process (AHP)

The security analysis is done for a flower shop system. Security vulnerabilities such as Cross Site Scripting (XSS) and SQL injection were deliberately implemented in the less secure version of the system. A MySql server and an Apache HTTP server were configured as a database server and web server respectively. The security analysis is performed by estimating the security risk. The risk values for various scenarios of different Eigen vectors and Eigen scores are given in Fig. 12.

Comparison of Risk Values of Flower Shop Software Architecture.

Construction and Exploitation of Flexibility in Software Architecture

An Airline Reservation System is taken as the example software architecture for the flexibility analysis [18]. Four scenarios are considered and the overall flexibility metric for these scenarios is 0.4.

Improving the Deployment Architecture of Software in Distributed Systems

Several algorithms like Mixed-Integer Nonlinear Programing (MINLP) algorithm, Mixed Integer linear Programming (MIP), Genetic algorithm and Greedy algorithm are considered for the security analysis in the distributed systems’ software architecture with 12 components, 8 users, 8 services, and 5 hosts. The comparison of the average security analysis among eight various services for these algorithms is shown in Fig. 13.

Comparison of Communication Security for Various Algorithms in a Distributed System.

Reliability Oriented Software Evolution Based on Contribution Degree of Component

The reliability analysis is performed for an ATM Banking System. Several scenarios such as Account Manager (R6), Helper (R7), Transactor (R9), Verifier (R10) and Messenger (R8) are used [24]. The reliability of two scenarios R6 and R7 are analyzed and shown in Fig. 14. The improved software architecture model provided a reliability of 54.51 %. After software evolution the reliability of the system increased to 85.12 %, which is a 56 % increase.

Comparison of Architecture Reliability for Two Scenarios Provided With Component Reliability.

Reliability Evaluation of Software Architecture under Uncertainty

A Monte Carlo (MC) simulation process has been considered for the analysis of reliability in the software architecture under uncertainty [43]. The analysis is based on 3000 MC trails. The histogram of the reliability samples is computed and is shown in Fig. 15.

Histogram of Reliability Samples.

Conclusion

The general software architecture has been analyzed in terms of performance, reliability, flexibility, adaptability and performance. Various techniques concentrating on individual performance parameters can be integrated for the efficient analysis and design of the software architecture. The various techniques to implement the fuzzy association rule have been discussed. The results of the software architecture analysis with respect to security, component reliability, architecture reliability, adaptability and risk value has been presented.