In the process of software architecture design, different decisions are made that have systemwide
impact. An important decision of design stage is the selection of a suitable software
architecture style. Lack of investigation on the quantitative impact of architecture styles on
software quality attributes is the main problem in using such styles. So, the use of architecture
styles in designing is based on the intuition of software developers. The aim of this research is
to quantify the impacts of architecture styles on software maintainability. In this study,
architecture styles are evaluated based on coupling, complexity and cohesion metrics and
ranked by analytic hierarchy process from maintainability viewpoint. The main contribution of
this paper is quantification and ranking of software architecture styles from the perspective of
maintainability quality attribute at stage of architectural style selection.
RELIABILITY EVALUATION OF SOFTWARE ARCHITECTURE STYLEScsandit
In process of software architecture design, different decisions with system-wide impacts are made. An important decision of design stage is the selection of appropriate software
architecture style. Since quantitative impacts of styles on quality attributes have not been studied yet, their application is not systematic. Since Reliability is one of the essential quality
requirements of software systems, especially for life critical ones, one of the main criteria in choosing architecture style of these systems is high reliability. The goal of this study is to
quantify the impact of architecture styles on software reliability that is desired quality of life critical software. We evaluate styles through reliability block diagram method. First, the
reliability equation of each architectural style was computed using of Reliability block diagram approach. Then, reliability rank of architectural styles is computed by setting of the number of effective components in a transaction parameter in reliability equation of architectural styles.
The main innovation of this article is quantification of impact of styles on software reliability that is essential for style selection.
Contributors to Reduce Maintainability Cost at the Software Implementation PhaseWaqas Tariq
Software maintenance is important and difficult to measure. The cost of maintenance is the most ever during the phases of software development. One of the most critical processes in software development is the reduction of software maintainability cost based on the quality of source code during design step, however, a lack of quality models and measures can help asses the quality attributes of software maintainability process. Software maintainability suffers from a number of challenges such as lack source code understanding, quality of software code, and adherence to programming standards in maintenance. This work describes model based-factors to assess the software maintenance, explains the steps followed to obtain and validate them. Such a method can be used to eliminate the software maintenance cost. The research results will enhance the quality of the source code. It will increase software understandability, eliminate maintenance time, cost, and give confidence for software reusability.
A methodology to evaluate object oriented software systems using change requi...ijseajournal
It is a well known fact that software maintenance plays a major role and finds importance in software
development life cycle. As object
-
oriented programming has become the standard, it is very important to
understand th
e problems of maintaining object
-
oriented software systems. This paper aims at evaluating
object
-
oriented software system through change requirement traceability
–
based impact analysis
methodology
for non functional requirements using functional requirem
ents
. The major issues have been
related to change impact algorithms and inheritance of functionality.
A reliability estimation framework for OO design complexity perspective has been developed inthis paper. The proposed framework correlates the object oriented design constructs with complexity and also correlates complexity with reliability. No such framework has been available in the literature that estimates software reliability of OO design by taking complexity into consideration. The framework bridges the gap between object oriented design constructs, complexity and reliability. Framework measures and minimizes the complexity of software design at the early stage of software development life cycle leading to a reliable end product. Reliability and complexity estimation models have been proposed by following the proposed framework. Complexity estimation model has been developed which takes OO design constructs into consideration and proposed reliability estimation models take complexity in consideration for estimating reliability of OO design.
One of the core quality assurance feature which combines fault prevention and fault detection, is often known as testability approach also. There are many assessment techniques and quantification method evolved for software testability prediction which actually identifies testability weakness or factors to further help reduce test effort. This paper examines all those measurement techniques that are being proposed for software testability assessment at various phases of object oriented software development life cycle. The aim is to find the best metrics suit for software quality improvisation through software testability support. The ultimate objective is to establish the ground work for finding ways reduce the testing effort by improvising software testability and its assessment using well planned guidelines for object-oriented software development with the help of suitable metrics.
Service oriented configuration management of software architectureIJNSA Journal
Software configuration management (SCM) is an important activity in the software engineering life cycle. SCM by control of the evolution process of products leads to constancy and stability in software systems. Nowadays, use of software configuration management is essential during the process of software development as rules to control and manage the evolution of software systems. SCM effects different levels of abstraction included the architectural level. Configuration of software architecture causes improvement in the configuration of the lower abstraction levels. CM of software architecture is more significant in large scale software with longevity of life cycle. Traditional SCM approaches, at the architectural level, do not provided the necessary support to software configuration management, so systems that use these approaches are faced with problems. These problems arise because of the lack of a serious constant and repeated changes in the software process. To overcome this it is necessary to create an infrastructure. Hence, a service oriented approach for configuration management is presented in this paper. In this approach, the activities of configuration management are conducted from a service oriented viewpoint. This approach was also used to try and control the evolution and number of versions of different software systems in order to identify, organize and control change and reforms during the production process. This approach can compose services and create composite services for new undefined activities of configuration.
An interactive approach to requirements prioritization using quality factorsijfcstjournal
As the prevalence of software increases, so does the complexity and the number of requirements assoc
iated
to the software project. This presents a dilemma for the developers to clearly identify and prioriti
ze the
most important requirements in order to del
iver the project in given amount of resources and time.
A
number of prioritization methods have been proposed which provide consistent results, but they are v
ery
difficult and complex to implement in practical scenarios as well as lack proper structure to
analyze the
requirements properly. In this study, the users can provide their requirements in two forms: text ba
sed
story form and use case form.
Moreover, the existing prioritization techniques have a very little or no
interaction with the users. So, in t
his paper an attempt has been made to make the prioritization process
user interactive by adding a second level of prioritization where after the developer has properly a
nalyzed
and ranked the requirements on the basis of quality attributes in the first le
vel, takes the opinion of distinct
user’s about the requirements priority sequence. The developer then calculates the disagreement valu
e
associated with each user sequence in order to find out the final priority sequence.
RELIABILITY EVALUATION OF SOFTWARE ARCHITECTURE STYLEScsandit
In process of software architecture design, different decisions with system-wide impacts are made. An important decision of design stage is the selection of appropriate software
architecture style. Since quantitative impacts of styles on quality attributes have not been studied yet, their application is not systematic. Since Reliability is one of the essential quality
requirements of software systems, especially for life critical ones, one of the main criteria in choosing architecture style of these systems is high reliability. The goal of this study is to
quantify the impact of architecture styles on software reliability that is desired quality of life critical software. We evaluate styles through reliability block diagram method. First, the
reliability equation of each architectural style was computed using of Reliability block diagram approach. Then, reliability rank of architectural styles is computed by setting of the number of effective components in a transaction parameter in reliability equation of architectural styles.
The main innovation of this article is quantification of impact of styles on software reliability that is essential for style selection.
Contributors to Reduce Maintainability Cost at the Software Implementation PhaseWaqas Tariq
Software maintenance is important and difficult to measure. The cost of maintenance is the most ever during the phases of software development. One of the most critical processes in software development is the reduction of software maintainability cost based on the quality of source code during design step, however, a lack of quality models and measures can help asses the quality attributes of software maintainability process. Software maintainability suffers from a number of challenges such as lack source code understanding, quality of software code, and adherence to programming standards in maintenance. This work describes model based-factors to assess the software maintenance, explains the steps followed to obtain and validate them. Such a method can be used to eliminate the software maintenance cost. The research results will enhance the quality of the source code. It will increase software understandability, eliminate maintenance time, cost, and give confidence for software reusability.
A methodology to evaluate object oriented software systems using change requi...ijseajournal
It is a well known fact that software maintenance plays a major role and finds importance in software
development life cycle. As object
-
oriented programming has become the standard, it is very important to
understand th
e problems of maintaining object
-
oriented software systems. This paper aims at evaluating
object
-
oriented software system through change requirement traceability
–
based impact analysis
methodology
for non functional requirements using functional requirem
ents
. The major issues have been
related to change impact algorithms and inheritance of functionality.
A reliability estimation framework for OO design complexity perspective has been developed inthis paper. The proposed framework correlates the object oriented design constructs with complexity and also correlates complexity with reliability. No such framework has been available in the literature that estimates software reliability of OO design by taking complexity into consideration. The framework bridges the gap between object oriented design constructs, complexity and reliability. Framework measures and minimizes the complexity of software design at the early stage of software development life cycle leading to a reliable end product. Reliability and complexity estimation models have been proposed by following the proposed framework. Complexity estimation model has been developed which takes OO design constructs into consideration and proposed reliability estimation models take complexity in consideration for estimating reliability of OO design.
One of the core quality assurance feature which combines fault prevention and fault detection, is often known as testability approach also. There are many assessment techniques and quantification method evolved for software testability prediction which actually identifies testability weakness or factors to further help reduce test effort. This paper examines all those measurement techniques that are being proposed for software testability assessment at various phases of object oriented software development life cycle. The aim is to find the best metrics suit for software quality improvisation through software testability support. The ultimate objective is to establish the ground work for finding ways reduce the testing effort by improvising software testability and its assessment using well planned guidelines for object-oriented software development with the help of suitable metrics.
Service oriented configuration management of software architectureIJNSA Journal
Software configuration management (SCM) is an important activity in the software engineering life cycle. SCM by control of the evolution process of products leads to constancy and stability in software systems. Nowadays, use of software configuration management is essential during the process of software development as rules to control and manage the evolution of software systems. SCM effects different levels of abstraction included the architectural level. Configuration of software architecture causes improvement in the configuration of the lower abstraction levels. CM of software architecture is more significant in large scale software with longevity of life cycle. Traditional SCM approaches, at the architectural level, do not provided the necessary support to software configuration management, so systems that use these approaches are faced with problems. These problems arise because of the lack of a serious constant and repeated changes in the software process. To overcome this it is necessary to create an infrastructure. Hence, a service oriented approach for configuration management is presented in this paper. In this approach, the activities of configuration management are conducted from a service oriented viewpoint. This approach was also used to try and control the evolution and number of versions of different software systems in order to identify, organize and control change and reforms during the production process. This approach can compose services and create composite services for new undefined activities of configuration.
An interactive approach to requirements prioritization using quality factorsijfcstjournal
As the prevalence of software increases, so does the complexity and the number of requirements assoc
iated
to the software project. This presents a dilemma for the developers to clearly identify and prioriti
ze the
most important requirements in order to del
iver the project in given amount of resources and time.
A
number of prioritization methods have been proposed which provide consistent results, but they are v
ery
difficult and complex to implement in practical scenarios as well as lack proper structure to
analyze the
requirements properly. In this study, the users can provide their requirements in two forms: text ba
sed
story form and use case form.
Moreover, the existing prioritization techniques have a very little or no
interaction with the users. So, in t
his paper an attempt has been made to make the prioritization process
user interactive by adding a second level of prioritization where after the developer has properly a
nalyzed
and ranked the requirements on the basis of quality attributes in the first le
vel, takes the opinion of distinct
user’s about the requirements priority sequence. The developer then calculates the disagreement valu
e
associated with each user sequence in order to find out the final priority sequence.
Changeability has a direct relation to software maintainability and has a major role in providing high quality maintainable and trustworthy software. The concept of Changeability is a major factor when we design and develop software and its constituents. Developing programs and its constituent components with good changeability continually improves and simplifies test operations and maintenance during and after implementation. It encourages and supports improvement in software quality at design stage in the development of software. The research here highlights the importance of changeability broadly and also as an important aspect of software quality.
Software Quality Engineering is a broad area that is concerned with various approaches to improve software quality. A quality model would prove successful when it suffices the requirements of the developers and the consumers. This research focuses on establishing semantics between the existing techniques related to the software quality engineering and thereby designing a framework for rating software quality.
INCREASING THE ARCHITECTURES DESIGN QUALITY FOR MAS: AN APPROACH TO MINIMIZE ...cscpconf
The efficiency of multi agent system design mainly relies on the quality of a conceptual architecture of such systems. Hence, quality issues should be considered at an early stage in the software development process. Large systems such as multi agents systems (MAS) require many communications and interactions to fulfil their tasks, and this leads to complexity of architecture design (AD) which have crucial influence on architecture design quality. This work attempts to introduce approach to increase the architecture design quality of MAS by minimizing the effect of complexity.
The objective of this paper is to provide an insight preview into various
agent oriented methodologies by using an enhanced comparison
framework based on criteria like process related criteria, steps and
techniques related criteria, steps and usability criteria, model related or
“concepts” related criteria, comparison regarding model related criteria
and comparison regarding supportive related criteria. The result also
constitutes inputs collected from the users of the agent oriented
methodologies through a questionnaire based survey.
The Impact of Software Complexity on Cost and Quality - A Comparative Analysi...ijseajournal
Early prediction of software quality is important for better software planning and controlling. In early
development phases, design complexity metrics are considered as useful indicators of software testing
effort and some quality attributes. Although many studies investigate the relationship between design
complexity and cost and quality, it is unclear what we have learned beyond the scope of individual studies.
This paper presented a systematic review on the influence of software complexity metrics on quality
attributes. We aggregated Spearman correlation coefficients from 59 different data sets from 57 primary
studies by a tailored meta-analysis approach. We found that fault proneness and maintainability are most
frequently investigated attributes. Chidamber & Kemerer metric suite is most frequently used but not all of
them are good quality attribute indicators. Moreover, the impact of these metrics is not different in
proprietary and open source projects. The result provides some implications for building quality model
across project type.
Software requirements prioritization is a
recognized practice in requirements engineering (RE)
that facilitates the management of stakeholders’
subjective views as specified in their requirements
listing. Since RE process is naturally collaborative in
nature, the intensiveness from both knowledge and
human perspectives opens up the problem of decision
making on requirements, which can be facilitated by
requirements prioritization. However, due to the large
volume of requirements elicited when considering an
ultra-large-scale system, existing prioritization
techniques proposed so far suffer some setbacks in
terms of efficiency, effectiveness and scalability. This
paper employed the use of a more efficient ranking
algorithm for requirements prioritization based on the
limitations of existing techniques. The major objective
is to provide a well-defined ranking procedure through
analysis, suitable for prioritizing software requirements.
An empirical evaluation of the proposed technique was
made using a typical scenario of the Pharmacy
Information System at the Obafemi Awolowo
University Teaching Hospital Complex (OAUTHC) as a
case study. The results showed the computation of the
positive ideal solution (PIS) and negative ideal solution
(NIS), as well as the closeness coefficient (CC) for 4
requirements across 3 stakeholders. The CC showed the
final ranks of requirements, where R4 with 2.09 point is
the most valued requirements, while R1 and R2 with
CC of 1.37 and 1.05 were next in the order of priority
respectively. The CC provides the medium through
which problems of multiple criteria decision making
can be handled, so as to determine the order of priority
of the available alternatives. The paper conveyed
encouraging evidence for the software engineering
community that is capable of resolving redundant
specified requirements, thereby providing the potential
that will facilitate effective and efficient decision
making in handling the differences amongst
requirements that have been prioritized. Thus,
prioritizing software requirements with the
recommended ranking procedure during software
development is crucial and vital in order to reduce
development cost.
Evaluating effectiveness factor of object oriented design a testability pers...ijseajournal
Effectiveness is important quality factor to testability measurement of object oriented software at an initial
stage of software development process exclusively at design phase for high quality product. It will help
developer’s design capability to achieve the specified functionalities, characteristics, better design quality
and behavior using appropriate object oriented design (OOD) concepts and procedures. Metric based
model for ‘Effectiveness Quantification Model of Object Oriented Design’ has been proposed by
establishing the correlation between effectiveness and OOD constructs. Later ‘Effectiveness Quantification
Model’ is empirically validated and statistical significance of the study considers the high correlation for
model acceptance. The aim of this research work is to encourage researchers and developers for inclusion
of the effectiveness quantification model to access and quantify software effectiveness quality factor at
design time.
TEST CASE PRIORITIZATION USING FUZZY LOGIC BASED ON REQUIREMENT PRIORITIZINGijcsa
Boolean expressions are popularly used for modelling decisions or conditions in specifications or source
programs and they are very much prone to introduction of faults. Even for a Boolean expression with few
numbers of literals the possible number of test cases can be quite large. Boolean expressions with n
variables require 2n
test cases to distinguish from faulty expression. In practice, n can be quite large and
there are examples of specification having Boolean expressions with 30 or more variables. To test a system
based on Boolean specification in limited time, it is not possible to execute all test cases so prioritization is
required which leads to early fault detection in testing life cycle. There are various testing strategies for
generation of test cases for Boolean specifications like MUMCUT, which generate fewer test cases then 2
n
with high probabilities of finding errors but their prioritization are not considering the criteria from user’s
perspective. We have proposed a new approach which prioritizes test cases based on requirement
prioritization. Our aim is to find the severe faults from user’s perspective early in the testing process and
hence to improve the quality of the software .This paper considers method for assigning weight value on the
basis of factors which generates the criteria for test case prioritization for Boolean Specifications. These
factors are: Business Value Measure (BVM), Project Change Volatility (PCV), and Development
Complexity (DC). Priority is assigned to test cases based upon these factors using fuzzy logic model.
THE UNIFIED APPROACH FOR ORGANIZATIONAL NETWORK VULNERABILITY ASSESSMENTijseajournal
The present business network infrastructure is quickly varying with latest servers, services, connections,
and ports added often, at times day by day, and with a uncontrollably inflow of laptops, storage media and
wireless networks. With the increasing amount of vulnerabilities and exploits coupled with the recurrent
evolution of IT infrastructure, organizations at present require more numerous vulnerability assessments.
In this paper new approach the Unified process for Network vulnerability Assessments hereafter called as
a unified NVA is proposed for network vulnerability assessment derived from Unified Software
Development Process or Unified Process, it is a popular iterative and incremental software development
process framework.
STATISTICAL ANALYSIS FOR PERFORMANCE COMPARISONijseajournal
Performance responsiveness and scalability is a make-or-break quality for software. Nearly everyone runs into performance problems at one time or another. This paper discusses about performance issues faced during Pre Examination Process Automation System (PEPAS) implemented in java technology. The challenges faced during the life cycle of the project and the mitigation actions performed. It compares 3 java technologies and shows how improvements are made through statistical analysis in response time of the application. The paper concludes with result analysis.
Integrating profiling into mde compilersijseajournal
Scientific computation requires more and more performance in its algorithms. New massively parallel
architectures suit well to these algorithms. They are known for offering high performance and power
efficiency. Unfortunately, as parallel programming for these architectures requires a complex distribution
of tasks and data, developers find difficult to implement their applications effectively. Although approaches
based on source-to-source intends to provide a low learning curve for parallel programming and take
advantage of architecture features to create optimized applications, programming remains difficult for
neophytes. This work aims at improving performance by returning to the high-level models, specific
execution data from a profiling tool enhanced by smart advices computed by an analysis engine. In order to
keep the link between execution and model, the process is based on a traceability mechanism. Once the
model is automatically annotated, it can be re-factored aiming better performances on the re-generated
code. Hence, this work allows keeping coherence between model and code without forgetting to harness the
power of parallel architectures. To illustrate and clarify key points of this approach, we provide an
experimental example in GPUs context. The example uses a transformation chain from UML-MARTE
models to OpenCL code.
La télévision par câble en France. Efficacité économique et concurrenceJérôme Perani
Réseaux, n° 80, novembre/décembre 1996
Cet article tente d'appliquer les principes de théorie économique au cas de la télévision par câble en France. A l'aide des méthodes d'analyse sectorielle de Michael Porter, il établit un bilan des forces concurrentielles qui exercent dans l'ensemble, en 1996, une pression peu importante sur le secteur des câblo-opérateurs. Cette analyse met à jour un important dérèglement des mécanismes concurrentiels : les câblo-opérateurs sont des monopoles locaux dont les prix ne sont pas réglementés, la concurrence des autres supports multicanaux est limitée alors que celle, forte, de la télévision hertzienne semble n'exercer aucune pression sur les prix des câble-opérateurs, les autorisations exclusives d'exploitation de réseaux câblés annullent toute menace d'entrée potentielle, le pouvoir de négociation des chaînes non intégrées verticalement est faible et les abonnés subissent les comportements monopolistiques des grands opérateurs. Une meilleure efficacité et un meilleur développement du marché du câble pourraient provenir théoriquement de l'introduction d'une concurrence frontale, d'une réglementation des prix des câblo-opérateurs et du développement d'une concurrence exercée par d'autres supports de distribution multicanaux.
Changeability has a direct relation to software maintainability and has a major role in providing high quality maintainable and trustworthy software. The concept of Changeability is a major factor when we design and develop software and its constituents. Developing programs and its constituent components with good changeability continually improves and simplifies test operations and maintenance during and after implementation. It encourages and supports improvement in software quality at design stage in the development of software. The research here highlights the importance of changeability broadly and also as an important aspect of software quality.
Software Quality Engineering is a broad area that is concerned with various approaches to improve software quality. A quality model would prove successful when it suffices the requirements of the developers and the consumers. This research focuses on establishing semantics between the existing techniques related to the software quality engineering and thereby designing a framework for rating software quality.
INCREASING THE ARCHITECTURES DESIGN QUALITY FOR MAS: AN APPROACH TO MINIMIZE ...cscpconf
The efficiency of multi agent system design mainly relies on the quality of a conceptual architecture of such systems. Hence, quality issues should be considered at an early stage in the software development process. Large systems such as multi agents systems (MAS) require many communications and interactions to fulfil their tasks, and this leads to complexity of architecture design (AD) which have crucial influence on architecture design quality. This work attempts to introduce approach to increase the architecture design quality of MAS by minimizing the effect of complexity.
The objective of this paper is to provide an insight preview into various
agent oriented methodologies by using an enhanced comparison
framework based on criteria like process related criteria, steps and
techniques related criteria, steps and usability criteria, model related or
“concepts” related criteria, comparison regarding model related criteria
and comparison regarding supportive related criteria. The result also
constitutes inputs collected from the users of the agent oriented
methodologies through a questionnaire based survey.
The Impact of Software Complexity on Cost and Quality - A Comparative Analysi...ijseajournal
Early prediction of software quality is important for better software planning and controlling. In early
development phases, design complexity metrics are considered as useful indicators of software testing
effort and some quality attributes. Although many studies investigate the relationship between design
complexity and cost and quality, it is unclear what we have learned beyond the scope of individual studies.
This paper presented a systematic review on the influence of software complexity metrics on quality
attributes. We aggregated Spearman correlation coefficients from 59 different data sets from 57 primary
studies by a tailored meta-analysis approach. We found that fault proneness and maintainability are most
frequently investigated attributes. Chidamber & Kemerer metric suite is most frequently used but not all of
them are good quality attribute indicators. Moreover, the impact of these metrics is not different in
proprietary and open source projects. The result provides some implications for building quality model
across project type.
Software requirements prioritization is a
recognized practice in requirements engineering (RE)
that facilitates the management of stakeholders’
subjective views as specified in their requirements
listing. Since RE process is naturally collaborative in
nature, the intensiveness from both knowledge and
human perspectives opens up the problem of decision
making on requirements, which can be facilitated by
requirements prioritization. However, due to the large
volume of requirements elicited when considering an
ultra-large-scale system, existing prioritization
techniques proposed so far suffer some setbacks in
terms of efficiency, effectiveness and scalability. This
paper employed the use of a more efficient ranking
algorithm for requirements prioritization based on the
limitations of existing techniques. The major objective
is to provide a well-defined ranking procedure through
analysis, suitable for prioritizing software requirements.
An empirical evaluation of the proposed technique was
made using a typical scenario of the Pharmacy
Information System at the Obafemi Awolowo
University Teaching Hospital Complex (OAUTHC) as a
case study. The results showed the computation of the
positive ideal solution (PIS) and negative ideal solution
(NIS), as well as the closeness coefficient (CC) for 4
requirements across 3 stakeholders. The CC showed the
final ranks of requirements, where R4 with 2.09 point is
the most valued requirements, while R1 and R2 with
CC of 1.37 and 1.05 were next in the order of priority
respectively. The CC provides the medium through
which problems of multiple criteria decision making
can be handled, so as to determine the order of priority
of the available alternatives. The paper conveyed
encouraging evidence for the software engineering
community that is capable of resolving redundant
specified requirements, thereby providing the potential
that will facilitate effective and efficient decision
making in handling the differences amongst
requirements that have been prioritized. Thus,
prioritizing software requirements with the
recommended ranking procedure during software
development is crucial and vital in order to reduce
development cost.
Evaluating effectiveness factor of object oriented design a testability pers...ijseajournal
Effectiveness is important quality factor to testability measurement of object oriented software at an initial
stage of software development process exclusively at design phase for high quality product. It will help
developer’s design capability to achieve the specified functionalities, characteristics, better design quality
and behavior using appropriate object oriented design (OOD) concepts and procedures. Metric based
model for ‘Effectiveness Quantification Model of Object Oriented Design’ has been proposed by
establishing the correlation between effectiveness and OOD constructs. Later ‘Effectiveness Quantification
Model’ is empirically validated and statistical significance of the study considers the high correlation for
model acceptance. The aim of this research work is to encourage researchers and developers for inclusion
of the effectiveness quantification model to access and quantify software effectiveness quality factor at
design time.
TEST CASE PRIORITIZATION USING FUZZY LOGIC BASED ON REQUIREMENT PRIORITIZINGijcsa
Boolean expressions are popularly used for modelling decisions or conditions in specifications or source
programs and they are very much prone to introduction of faults. Even for a Boolean expression with few
numbers of literals the possible number of test cases can be quite large. Boolean expressions with n
variables require 2n
test cases to distinguish from faulty expression. In practice, n can be quite large and
there are examples of specification having Boolean expressions with 30 or more variables. To test a system
based on Boolean specification in limited time, it is not possible to execute all test cases so prioritization is
required which leads to early fault detection in testing life cycle. There are various testing strategies for
generation of test cases for Boolean specifications like MUMCUT, which generate fewer test cases then 2
n
with high probabilities of finding errors but their prioritization are not considering the criteria from user’s
perspective. We have proposed a new approach which prioritizes test cases based on requirement
prioritization. Our aim is to find the severe faults from user’s perspective early in the testing process and
hence to improve the quality of the software .This paper considers method for assigning weight value on the
basis of factors which generates the criteria for test case prioritization for Boolean Specifications. These
factors are: Business Value Measure (BVM), Project Change Volatility (PCV), and Development
Complexity (DC). Priority is assigned to test cases based upon these factors using fuzzy logic model.
THE UNIFIED APPROACH FOR ORGANIZATIONAL NETWORK VULNERABILITY ASSESSMENTijseajournal
The present business network infrastructure is quickly varying with latest servers, services, connections,
and ports added often, at times day by day, and with a uncontrollably inflow of laptops, storage media and
wireless networks. With the increasing amount of vulnerabilities and exploits coupled with the recurrent
evolution of IT infrastructure, organizations at present require more numerous vulnerability assessments.
In this paper new approach the Unified process for Network vulnerability Assessments hereafter called as
a unified NVA is proposed for network vulnerability assessment derived from Unified Software
Development Process or Unified Process, it is a popular iterative and incremental software development
process framework.
STATISTICAL ANALYSIS FOR PERFORMANCE COMPARISONijseajournal
Performance responsiveness and scalability is a make-or-break quality for software. Nearly everyone runs into performance problems at one time or another. This paper discusses about performance issues faced during Pre Examination Process Automation System (PEPAS) implemented in java technology. The challenges faced during the life cycle of the project and the mitigation actions performed. It compares 3 java technologies and shows how improvements are made through statistical analysis in response time of the application. The paper concludes with result analysis.
Integrating profiling into mde compilersijseajournal
Scientific computation requires more and more performance in its algorithms. New massively parallel
architectures suit well to these algorithms. They are known for offering high performance and power
efficiency. Unfortunately, as parallel programming for these architectures requires a complex distribution
of tasks and data, developers find difficult to implement their applications effectively. Although approaches
based on source-to-source intends to provide a low learning curve for parallel programming and take
advantage of architecture features to create optimized applications, programming remains difficult for
neophytes. This work aims at improving performance by returning to the high-level models, specific
execution data from a profiling tool enhanced by smart advices computed by an analysis engine. In order to
keep the link between execution and model, the process is based on a traceability mechanism. Once the
model is automatically annotated, it can be re-factored aiming better performances on the re-generated
code. Hence, this work allows keeping coherence between model and code without forgetting to harness the
power of parallel architectures. To illustrate and clarify key points of this approach, we provide an
experimental example in GPUs context. The example uses a transformation chain from UML-MARTE
models to OpenCL code.
La télévision par câble en France. Efficacité économique et concurrenceJérôme Perani
Réseaux, n° 80, novembre/décembre 1996
Cet article tente d'appliquer les principes de théorie économique au cas de la télévision par câble en France. A l'aide des méthodes d'analyse sectorielle de Michael Porter, il établit un bilan des forces concurrentielles qui exercent dans l'ensemble, en 1996, une pression peu importante sur le secteur des câblo-opérateurs. Cette analyse met à jour un important dérèglement des mécanismes concurrentiels : les câblo-opérateurs sont des monopoles locaux dont les prix ne sont pas réglementés, la concurrence des autres supports multicanaux est limitée alors que celle, forte, de la télévision hertzienne semble n'exercer aucune pression sur les prix des câble-opérateurs, les autorisations exclusives d'exploitation de réseaux câblés annullent toute menace d'entrée potentielle, le pouvoir de négociation des chaînes non intégrées verticalement est faible et les abonnés subissent les comportements monopolistiques des grands opérateurs. Une meilleure efficacité et un meilleur développement du marché du câble pourraient provenir théoriquement de l'introduction d'une concurrence frontale, d'une réglementation des prix des câblo-opérateurs et du développement d'une concurrence exercée par d'autres supports de distribution multicanaux.
Le vie del mare: traffico merci in Italia e nell'area Euro-MediterraneaCarlo Romagnoli
Analisi a tutto campo sul traffico marittimo di merci nell'area euro-mediterranea, con informazioni dettagliate su flussi complessivi inbound e outgoing e posizionamento competitivo dei principali scali portuali del Mediterraneo.
EVALUATION OF THE SOFTWARE ARCHITECTURE STYLES FROM MAINTAINABILITY VIEWPOINTcscpconf
In the process of software architecture design, different decisions are made that have systemwide
impact. An important decision of design stage is the selection of a suitable software
architecture style. Lack of investigation on the quantitative impact of architecture styles on
software quality attributes is the main problem in using such styles. So, the use of architecture
styles in designing is based on the intuition of software developers. The aim of this research is
to quantify the impacts of architecture styles on software maintainability. In this study,
architecture styles are evaluated based on coupling, complexity and cohesion metrics and
ranked by analytic hierarchy process from maintainability viewpoint. The main contribution of
this paper is quantification and ranking of software architecture styles from the perspective of
maintainability quality attribute at stage of architectural style selection.
RELIABILITY EVALUATION OF SOFTWARE ARCHITECTURE STYLEScscpconf
In process of software architecture design, different decisions with system-wide impacts are made. An important decision of design stage is the selection of appropriate software architecture style. Since quantitative impacts of styles on quality attributes have not been
studied yet, their application is not systematic. Since Reliability is one of the essential quality requirements of software systems, especially for life-critical ones, one of the main criteria in choosing architecture style of these systems is high reliability. The goal of this study is to
quantify the impact of architecture styles on software reliability that is desired quality of life-critical software. We evaluate styles through reliability block diagram method. First, the reliability equation of each architectural style was computed using of Reliability block diagram
approach. Then, reliability rank of architectural styles is computed by the setting of the number of effective components in a transaction parameter in reliability equation of architectural styles. The main innovation of this article is quantification of impact of styles on software reliability
that is essential for style selection
AN IMPROVED REPOSITORY STRUCTURE TO IDENTIFY, SELECT AND INTEGRATE COMPONENTS...ijseajournal
An ultimate goal of software development is to build high quality products. The customers of software
industry always demand for high-quality products quickly and cost effectively. The component-based
development (CBD) is the most suitable methodology for the software companies to meet the demands of
target market. To opt CBD, the software development teams have to customize generic components that are
available in the market and it is very difficult for the development teams to choose the suitable components
from the millions of third party and commercial off the shelf (COTS) components. On the other hand, the
development of in-house repository is tedious and time consuming. In this paper, we propose an easy and
understandable repository structure to provide helpful information about stored components like how to
identify, select, retrieve and integrate components. The proposed repository will also provide previous
assessments of developers and end-users about the selected component. The proposed repository will help
the software companies by reducing the customization effort, improving the quality of developed software
and preventing integrating unfamiliar components.
Changeability has a direct relation to software maintainability and has a major role in providing high quality maintainable and trustworthy software. The concept of Changeability is a major factor when we design and develop software and its constituents. Developing programs and its constituent components with good changeability continually improves and simplifies test operations and maintenance during and after implementation. It encourages and supports improvement in software quality at design stage in the development of software. The research here highlights the importance of changeability broadly and also as an important aspect of software quality.
In this paper a correlation between the major attributes of object oriented design and changeability has been ascertained. A changeability evaluation model using multiple linear regression has been proposed for object oriented design. The validation of the proposed changeability evaluation model is made known by means of experimental tests and the results show that the model is highly significant.
A Survey of Synergistic Relationships For Designing Architecture: Scenarios, ...ijbuiiir1
Software Architectures are generally designed with particular functional and nonfunctional requirements. Organizations often need to choose Software Architecture for future development from several contending candidate architectures. Several methods have been proposed to design, analyze, selecting architectures with respect to hoped quality attributes to identify their restrictions. Most of these methods encourage the use of architectural patterns to develop architectures with known characteristics and apply scenarios to evaluate those architectures for desired quality attributes (e.g., reliability, modifiability). In case of Architecting a complex design activity, it involves making decisions about a number of inter-dependent design choices that relate to a range of design concerns. Each decision requires selecting among a number of alternatives; each of which impacts differently on various quality attributes (e.g., real-time, reliability, and performance). This paper discusses a selection framework based on multiattribute decision making using Hypothetical Equivalents, Architectural Information in a format that can support design decisions, ArchDesigner as a taxonomic approach along with GB case study and a Reasoning Framework which is encapsulation mechanism, can be used by nonexperts to examine a specific quality (e.g., performance, modifiability, availability) of a system.
A Review on Quality Assurance of Component- Based Software Systemiosrjce
IOSR Journal of Computer Engineering (IOSR-JCE) is a double blind peer reviewed International Journal that provides rapid publication (within a month) of articles in all areas of computer engineering and its applications. The journal welcomes publications of high quality papers on theoretical developments and practical applications in computer technology. Original research papers, state-of-the-art reviews, and high quality technical notes are invited for publications.
The increasing availability of COTS (commercial-off-the-shelf) components in the market of software
development has concretized the opportunity of building whole systems based on previously built components. Component-
Based Software Engineering (CBSE) is an approach which is used to improve efficiency and productivity of software system
with the help of reusability. CBSE approach improves software development productivity and software quality by selecting
pre-existing software components. Reusability in Component-Based Software Development (CBSD) not only reduces the
time to market in development but also brings the cost down of development heavily. This paper represents the challenges
which are faced by software developer during component selection like reliability, time, components size, fault tolerance,
performance, components functionality and components compatibility. This paper also summarizes algorithms used for
component retrieval according to availability of component subset.
SERVICE ORIENTED CONFIGURATION MANAGEMENT OF SOFTWARE ARCHITECTUREIJNSA Journal
Software configuration management (SCM) is an important activity in the software engineering life cycle. SCM by control of the evolution process of products leads to constancy and stability in software systems. Nowadays, use of software configuration management is essential during the process of software development as rules to control and manage the evolution of software systems. SCM effects different levels of abstraction included the architectural level. Configuration of software architecture causes improvement in the configuration of the lower abstraction levels. CM of software architecture is more significant in large scale software with longevity of life cycle. Traditional SCM approaches, at the architectural level, do not provided the necessary support to software configuration management, so systems that use these approaches are faced with problems. These problems arise because of the lack of a serious constant and repeated changes in the software process. To overcome this it is necessary to create an infrastructure. Hence, a service oriented approach for configuration management is presented in this paper. In this approach, the activities of configuration management are conducted from a service oriented viewpoint. This approach was also used to try and control the evolution and number of versions of different software systems in order to identify, organize and control change and reforms during the production process. This approach can compose services and create composite services for new undefined activities of configuration.
SIZE METRICS FOR SERVICE-ORIENTED ARCHITECTUREmathsjournal
Determining the size, effort and cost of Service-oriented Architecture (SOA) systems is important to
facilitate project planning and eventually successful implementation of a software project. SOA approach is
one of the recent software architectures that allow integration of applications within and outside the
organization regardless of heterogeneous technology over a distributed network. A number of research
studies have been done to measure SOA size.However, these studies are not based on software metrics
rendering them to be ineffective in their estimation. This study defined a set of SOA size metrics based on
Unified Modelling Language (UML). The study employed Briand’s theoretical validation to test the validity
of the designed SOA size metrics. Findings from this study will provide metrics to measure SOA size more
accurately and form a basis for future software engineering researchers to develop more effective and more
accurate size metrics and effort estimation methods.
Size Metrics for Service-Oriented Architecture ijseajournal
Determining the size, effort and cost of Service-oriented Architecture (SOA) systems is important to facilitate project planning and eventually successful implementation of a software project. SOA approach is one of the recent software architectures that allow integration of applications within and outside the organization regardless of heterogeneous technology over a distributed network. A number of research
studies have been done to measure SOA size.However, these studies are not based on software metrics rendering them to be ineffective in their estimation. This study defined a set of SOA size metrics based on Unified Modelling Language (UML). The study employed Briand’s theoretical validation to test the validity
of the designed SOA size metrics. Findings from this study will provide metrics to measure SOA size more accurately and form a basis for future software engineering researchers to develop more effective and more accurate size metrics and effort estimation methods.
The most important aim of software engineering is to improve software productivity and quality of software product and further reduce the cost of software and time using engineering and management techniques.Broadly speaking, software engineering initiative has been introduced during software crisis period to describe the collection of techniques that apply engineering and management skills to the construction and
support of software process and products. There is no universally agreed theory for software measurement and the software metrics are useful for obtaining the information on evaluation of process and product in software engineering. It helps to plan and carry out improvement in software organizations and to provide objective information about project performance, process capability and product quality. The process capability is extremely important for software industry because the quality of products is largely determined by the quality of the processes. The make use of of existing metrics and development of innovative software metrics will be important factors in future software engineering process and product development. In future, research work will be based on using software metrics in software development for the development of the time schedule, cost estimates and software quality and can be improved through software metrics. The permanent application of measurement based methodologies is used to the software process and its products to provide important and timely management information, together with the use of those techniques to improve that software process and its products. This research paper mainly concentrates on the overview of unique basics of software measurement and exclusive fundamentals of software metrics in software engineering.
IMPLEMENTATION OF DYNAMIC COUPLING MEASUREMENT OF DISTRIBUTED OBJECT ORIENTED...IJCSEA Journal
Software metrics are increasingly playing a central role in the planning and control of software development projects. Coupling measures have important applications in software development and maintenance. Existing literature on software metrics is mainly focused on centralized systems, while work in the area of distributed systems, particularly in service-oriented systems, is scarce. Distributed systems with service oriented components are even more heterogeneous networking and execution environment. Traditional coupling measures take into account only “static” couplings. They do not account for “dynamic” couplings due to polymorphism and may significantly underestimate the complexity of software and misjudge the need for code inspection, testing and debugging. This is expected to result in poor predictive accuracy of the quality models in distributed Object Oriented systems that utilize static coupling measurements. In order to overcome these issues, we propose a hybrid model in Distributed Object Oriented Software for measure the coupling dynamically. In the proposed method, there are three steps such as Instrumentation process, Post processing and Coupling measurement. Initially the instrumentation process is done. In this process the instrumented JVM that has been modified to trace method calls. During this process, three trace files are created namely .prf, .clp, .svp. In the second step, the information in these file are merged. At the end of this step, the merged detailed trace of each JVM contains pointers to the merged trace files of the other JVM such that the path of every remote call from the client to the server can be uniquely identified. Finally, the coupling metrics are measured dynamically. The implementation results show that the proposed system will effectively measure the coupling metrics dynamically.
IMPLEMENTATION OF DYNAMIC COUPLING MEASUREMENT OF DISTRIBUTED OBJECT ORIENTED...IJCSEA Journal
Software metrics are increasingly playing a central role in the planning and control of software development projects. Coupling measures have important applications in software development and maintenance. Existing literature on software metrics is mainly focused on centralized systems, while work in the area of distributed systems, particularly in service-oriented systems, is scarce. Distributed systems with service oriented components are even more heterogeneous networking and execution environment. Traditional coupling measures take into account only “static” couplings. They do not account for “dynamic” couplings due to polymorphism and may significantly underestimate the complexity of software and misjudge the need for code inspection, testing and debugging. This is expected to result in poor predictive accuracy of the quality models in distributed Object Oriented systems that utilize static coupling measurements. In order to overcome these issues, we propose a hybrid model in Distributed Object Oriented Software for measure the coupling dynamically. In the proposed method, there are three steps
such as Instrumentation process, Post processing and Coupling measurement. Initially the instrumentation process is done. In this process the instrumented JVM that has been modified to trace method calls. During this process, three trace files are created namely .prf, .clp, .svp. In the second step, the information in these file are merged. At the end of this step, the merged detailed trace of each JVM contains pointers to the merged trace files of the other JVM such that the path of every remote call from the client to the server can be uniquely identified. Finally, the coupling metrics are measured dynamically. The implementation results show that the proposed system will effectively measure the coupling metrics dynamically.
The peer-reviewed International Journal of Engineering Inventions (IJEI) is started with a mission to encourage contribution to research in Science and Technology. Encourage and motivate researchers in challenging areas of Sciences and Technology.
Software quality model based on development team characteristicsIJECEIAES
Many factors have a significant impact on producing high-quality software products. Development team members are among the most important factors. Paying attention to the quality from this perspective will be a good innovation in the software development industry. Given that team members play a very important role in software products, this study tries to focus specifically on team characteristics in software product quality and provide a qualitative model based on this. The required data were collected through observations and interviews with project managers and development team members in several companies under study. Then, data were analyzed through hierarchical analysis. According to the results, the use of this model led to the improvement of the software development process so that the team members were satisfied with it. Also, time management was improved, and the customer expressed his satisfaction with the use of this model. Finally, data analysis showed that this model may lead to faster product delivery.
Similar to Evaluation of the software architecture styles from maintainability viewpoint (20)
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
2. 184
Computer Science & Information Technology (CS & IT)
system’s energy consumption has been estimated in [3]. A method for specifying the relation
between six SASs and quality attributes such as maintainability has been proposed in [8]. The
relationship between the quality attributes, design principles and some SASs has been specified in
[8] using a tree-based framework. In [4], the impacts of SASs on quality attributes are determined
based on the description of style in [2]. The methods offered in [4] and [8] are not able to
determine the amount of style support from quality attributes, do not offer quantitative results
about their maintainability, and are not precise. SASs are evaluated in [9] from maintainability
viewpoint based on the scenario-based evaluation method that is less precise, less reliable and less
analyzable as compared to the measurement-based evaluation method utilized in this paper.
In [10], the performance of three SASs has been investigated through simulation-based evaluation
method. Implicit/invocation style has been verified in [11], by model checking method.
In this study, the quantitative impact of SASs on software maintainability, one of the important
quality attributes required by all software, is determined based on the measurement-based
evaluation of SASs. The SASs evaluated include Repository (PRS), Blackboard (BKB), Pipe and
Filter (P/F), Layered (LYD), Implicit/Invocation (I/I), Client/Server(C/S), Broker (BRK) and
Object-Oriented (OO), which have been introduced in [2], [12].
Software architecture evaluation methods include: 1) scenario-based evaluation, 2) simulationbased evaluation, 3) measurement-based evaluation and 4) mathematic model-based evaluation.
Measurement-based evaluation method uses metrics to measure software architecture. Metrics
evaluate internal attributes of software (e.g. coupling). External attributes (e.g. maintainability)
reflect those properties that are desirable for the software user and usually are evaluated by
internal attributes. It is believed that there is a relationship between internal and external quality
attributes. This relationship is based on theoretical models and empirical study [13], [14]. There is
a general agreement in software community that modularity has an influence on external
attributes such as maintainability [15]. Therefore, in this paper, we use coupling, complexity and
cohesion metrics to quantify the impact of SASs on software maintainability. These metrics are
essential in evaluation of software design quality and their effects on maintainability have been
extensively investigated [15]-[18].
The advantage of measurement-based evaluation as compared to scenario-based evaluation is that
the evaluation would be easier and more precise, if there are appropriate metrics. In addition, it
does not have the problems of scenario-based evaluation, namely the dependency of the results on
the scenarios used, and extensive participation of the expert. As a result, the problem is evaluated
more comprehensively.
Multi-criteria decision-making methods are used in the ranking problem of SASs. These methods
are in three categories: 1) scoring, 2) compromise and 3) concordance [19]. Analytic hierarchy
process (AHP) [20] is one of the most comprehensive multi-criteria decision making methods. It
structures the problem as a hierarchy and provides a means of decomposing the problem into a
hierarchy of sub problems that can more easily be comprehended and subjectively evaluated.
AHP reflects the way people think and behave. It also considers different quantitative and
qualitative criteria in the problem and provides sensitivity analysis on the criteria and sub-criteria.
The AHP has been proven a theoretically sound, market-tested and accepted methodology.
In this paper, to rank SASs based on the results of measurement-based evaluation of SASs, AHP
method is used.
This paper is structured as follows: Section 2 discusses software maintainability and its
measurement metrics. Section 3 explains the quantitative measurement of SASs. Section 4 deals
with the ranking of SASs. Finally, Section 5 presents the conclusion.
3. Computer Science & Information Technology (CS & IT)
185
2. SOFTWARE MAINTAINABILITY AND ITS MEASUREMENT METRICS
The main objective of any software is to offer desired services according to the predetermined
quality level. There is a strong connection between many quality attributes and the software
architecture of the software system. The architecture defines the overall potential that a software
system possesses to fulfil certain quality attributes. Software are often redesigned not for the
deficiency in the functionality, but due to difficulty in maintenance, port or scale [21].
Maintainability is the capability of the software product to be modified [22]. Modifications may
include corrections, improvements or adaptations of the software to changes in the environment
and in the requirements and functional specifications. The ease of software correction is
determined through: 1) analyzability, 2) changeability, (3) stability and (4) testability [22].
A close look at software maintainability attributes reveals that provision of each characteristic
depends on the amount of modularity of software design, design with low coupling among
modules, low complexity of the modules and high cohesion of modules. Therefore, the less is the
amount of coupling and complexity of the components and the more their cohesion, the easier
will be the analyzability, changeability, stability and testability of the software. Various
researches emphasize the impact of complexity, cohesion of components and coupling among
components metrics on software maintainability [15]-[18].
2.1. Coupling Metric
High interaction of modules makes the understanding and modification of the modules more
difficult [15]. The more independent the components, the easier their understanding, modification
and maintainability [16]. Coupling is a complex concept that has been categorized by Yourdon
and Constantine [23] as: 1) Data coupling, 2) Stamp coupling, 3) Control coupling, 4) Shared
coupling and 5) Content coupling.
In this work, we generalize the “coupling among modules” concept to the coupling among
software architecture components and use it to measure the amount of coupling of SASs.
Components of SASs investigated in this work have three coupling types: data, stamp and shared
quantified based on Table 1. In [24] also consecutive numeric values from 1 to 5 were used and
the basis of such assignment was the experience from some software systems
Table 1.Type of Components Coupling
Row
1
2
3
Coupling type
Data
Stamp
Common
Symbol
w1
w2
w3
Weight
1
2
4
designs. Regarding the coupling metric, SASs are investigated in terms of the type of coupling
among the components and the number of components involved in the coupling. The more the
strength of coupling among components and the more the number of components involved in the
coupling, the less the understandability, correction and maintainability of the components [15].
To measure the coupling value of any SAS, (1) is used that is Euclidean norm, where n is the
number of style components, SCP is the amount of SAS coupling and CCPi is the amount of
coupling of the i-th component. CCPi is computed by (2), where NCTj is the number of type j
couplings, wj is the weight of the corresponding coupling type and p is the number of coupling of
the component i:
4. 186
Computer Science & Information Technology (CS & IT)
n
∑ CCP
SCP =
2
(1)
i
i =1
p
(2)
CCPi = ∑ NCT j .w j
j =1
2.2. Complexity Metric
Complexity value of SASs is computed by (3) where, SCM is the complexity of SAS, n is the
number of style components and CCMi is the amount of complexity of the i-th component. CCMi
is computed by (4), using the module evaluation metric of Shepperd et al [25], where fin(i) is the
fan-in of component i and fout(i) is the fan-out of component i.
n
SCM =
∑ CCM
2
i
(3)
i =1
CCMi =[fin(i)*fout(i)]2
(4)
fin(i) and fout(i) are computed by (5) and (6). In (5), Nci is the sum of the number of invocations of
component i by other components and Nri is the number of data that component i has retrieved
from the repository. In (6), Ncei is the number of other components called by component i and
Nui is the number of the repository data updated by component i. A component that controls a lot
of components usually performs various functions and so it will have a high complexity [15],[26].
fin(i)=Nci+Nri
(5)
fout(i)=Ncei+Nui
(6)
2.3. Cohesion Metric
The cohesion of a module is the extent to which its individual components are needed to perform
the same task. Types of cohesion are: 1) Coincidental, 2) Logical, 3) Temporal, 4) Procedural, 5)
Communicational, 6) Sequential and 7) Functional [23]. The cohesion type of every component is
computed based on the available information of functionality of each component of SASs
regarding the definition of the type of component cohesion in Table 2 [26].
In this work, we generalize the “modules cohesion” concept to the cohesion of software
architecture components and use it to measure the amount of cohesion of SASs. Our
investigations showed that cohesion of SASs in component are of three types: Functional,
Communicational and Logical, which are quantified based on Table 2.
Table 2. Type of Components Cohesion [26]
Cohesion type
Logical
Communicational
Functional
Description
Component performs multiple functions, and in
each calling, one of them is executed
Component refers to the same data set and/or
creates the same data set
Component performs a single well-defined
function
Symbol
C1
Weight
1
C2
2
C3
3
5. Computer Science & Information Technology (CS & IT)
187
Since every component i may have different type of cohesion (Cj), so the cohesion type of
component i, CCHi, is computed by (7). Finally, cohesion of SASs is computed by (8).
CCH i = arg min C j
(7)
j
n
SCH =
∑ CCH
2
i
(8)
i =1
3. Quantitative Measurement of SASs
In this section, SASs are measured from the viewpoint of maintainability based on coupling,
complexity and cohesion metrics.
The effect of software size on SASs ranking is taken into account in the computations of this
section. In object-oriented style, the number of objects (no) and in other SASs, the number of
components (n) correspond the software size. So in the evaluations done in this section, the
number of SASs components is considered as 3, 4, 5, 6, 7, 8 and 9 and the number of classes in
object-oriented style is considered accordingly as 21, 28, 35, 42, 49, 56 and 63.
3.1. Measuring the Coupling of SASs
In this section, the coupling formula of every SAS is computed using (1) to (2).
A. Repository style. In this style, all components have common coupling with the repository.
Therefore, any change in the repository affects them. If the number of components in the
repository style is n, then the number of couplings in this style will be n as well. Thus coupling of
repository style is obtained from n . w3 .
B. Blackboard style. The control component has a common coupling with the blackboard and
has data coupling with the knowledge resources. Therefore, the control component has one
common coupling and n data coupling while the knowledge resources have a common coupling
with the blackboard. Thus, the coupling of the control component is n.w1+ w3 and the coupling
of each knowledge resource is w3. Then coupling of this style is obtained from
2
(n.w1 + w3 )2 + n.w3 .
C. Pipe and filter style Every filter (component) has a stamp coupling with the next filter while
the last filter has no coupling with any other filter. The number of couplings is n-1, and regarding
the coupling type, the coupling of this style is obtained from n − 1 w2
D. Layered style The coupling type of every layer (component) with its lower layer is data.
Considering the fact that coupling is two way, the last and first layers have only one coupling
while other layers have two couplings. So for n layer, the coupling of this style is obtained from
4 ( n − 2 ).W12 + 2 .W12 .
E. Implicit invocation style. If, in average, n/2 of components publish the events that are favored
by n/2 of the components, the coupling type of the event publisher component with the dispatcher
component is data. If an event occurs, the dispatcher component invokes the interested
components, so the coupling type of the dispatcher component with the interested components is
6. 188
Computer Science & Information Technology (CS & IT)
data, and the coupling of the dispatcher component will be (n/2).w1. The coupling type of
independent components (n/2) is data, so coupling of this style is obtained from
(( n / 2). w1) 2 + ( n / 2). w1 2
.
F. Client/server style. The coupling of the client with the server is data type. Supposing that, in
average, the coupling of each server component is f and, since some server components are in
transaction and usually the last component is related to repository, thus about r % of the
components have just one connection with the repository. So, coupling of this style is obtained
2
from w12 + (1 − r )n( f .w1 )2 + rnw3 .
G. Broker style. Coupling of all components is data type. Considering these facts: (1) the client
component is related to the client side proxy, (2) the client is related to the broker in order to be
informed of different services of the server, (3) the server side proxy is coupled with the broker,
(4) the broker is coupled with the server side proxy and (5) the broker is coupled with the server
for being informed of different type of services of the server, and also considering the similarity
of the coupling of the server components to client/server style, the style coupling is obtained from
2
8w12 + (1 − r )n( f .w1 ) 2 + r.n.w3 .
H. Object oriented style. In this style, the type of coupling is data. A case study done by Yu and
Ramaswamy [28] on components dependency showed that 83% of the couplings between classes
are of parameter (data) type. Coupling of each class with other classes is considered as fo. So style
coupling is obtained from f o no . 1 .
w
Column 2 of Table 3 shows the coupling formulas of SASs. The third column shows the coupling
value obtained by replacing the weight of coupling type based on Table 1.
Table 3. Coupling Formulas of SASs
Symbol
RPS
Coupling Formula
n.w
3
Coupling Value
3 n
2
2
3
(n + 3)2 + 9n
BKB
(n.w + w3) + n.w
1
P/F
n − 1 w2
LYD
4(n − 2).W12 + 2.W12
4n − 6
I/I
((n / 2).w)2 + (n / 2).w 2
1
1
(n / 2)2 + (n / 2)
C/S
2
w12 + (1 − r ) n( f .w1 ) 2 + rnw3
1+ (1− r)n. f 2 + 9.r.n
BRK
2
8w12 + (1 − r)n( f .w1 )2 + r.n.w3
8+(1−r)n. f 2 +9.r..n
OO
f o n o . w1
2 n −1
fo
no
The coupling value of classes in object-oriented style (fo) is related to the designing manner of the
past software systems. This is true for the coupling value of server components (f) in the broker
and client/server styles as well. Therefore, software designers determine the average value of
coupling (i.e. f and fo) by referring to the previous software design records. For displaying the
relationship between coupling value and software size, it is necessary that first the values of f , r
and fo parameters are determined. Thus, documents of software design projects of a large and
7. Computer Science & Information Technology (CS & IT)
189
valid software company in Iran is investigated. Accordingly, after computations, the values of
these parameters become f=1.65 and fo=1.5 and r=0.2. By setting the parameters of f, fo and r to
the designated formulas and parameters n and no, the coupling value of SASs is computed
considering the software size (number of components), and its diagram is shown in figure 1.
According to this diagram, the coupling value of SASs is increased by increasing of the software
size.
Figure 1. Coupling value of SASs based on the size of software
3.2. Measuring the Complexity of SASs
In this section, the complexity formula of every SASs is computed using (3) to (6).
A. Repository style. In this style, all components read from the data repository and modify it.
Thus, both their fan-in and fan-out is equal to 1. Therefore, the total fan-out of each component,
considering the writing in the repository and invoking the repository for this writing, is 3. Thus
the complexity of independent components is 9 and the complexity of style is obtained from
9 n.
B. Blackboard style. The fan-in of the control component is 1 (for examining the status of the
blackboard) and its fan-out is 2 (for invoking the blackboard for reading its status and invoking
the knowledge resources). The fan-in of knowledge resources is 2 (for invoking by the control
component and reading from the blackboard) and its fan-out is 3 (for invocation of the blackboard
for reading and writing into the blackboard). So the complexity of the control component is 22,
the complexity of each of the knowledge resource is 36, and complexity of style is obtained
2
from 42 +36 n .
C. Pipe and filter style. The first filter (component) has no input and the last filter does not have
any output. Thus, their complexity is 0. The other filters have one input and one output. So the
complexity of style is obtained from. n −2
D. Layered style. In this style, the relation of lower layer to upper layer is response to the request
of upper layer, so in computing of layer's fan-out, this relation is ignored, i.e. only upper layer
invokes lower layer. Thus, each layer has fan-in and fan-out equal to 1. None of the layers does
not invoke first layer and the last layer invokes no layer. So their complexity is 0 and the
complexity of style is obtained from n − 2 .
8. 190
Computer Science & Information Technology (CS & IT)
E. Implicit invocation style. With the occurrence of an event, the dispatcher component invokes
the interested components. Therefore, the fan-in of dispatcher component is 1 (for occurrence of
the event that led to the invoking of the interested component by the dispatcher component) and
its fan-out is 1 (for invocation of the interested component, when an event occurs). Therefore, its
complexity is 1. The complexity of event publisher due to lack of fan-in and the complexity of
interested components due to lack of fan-out is 0. Therefore, the complexity of style is 1.
F. Client/server style. The client component invokes a procedure from the server, so fan-in of
the server and fan-out of the client is equal to 1. Since the client is not invoked by the components
and has no direct access to the repository, its fan-in is equal to 0 and its complexity is 0. The
number of fan-ins and fan-outs of the server components, in average, is considered as f. So the
complexity of each server component is f 4 and the complexity of style is f
4
n.
G. Broker style. The client component gets informed of the services of the server through the
method interface of the server that has been offered to the broker component, so both fan-in and
fan-out of the server becomes 1. In addition, fan-in of the broker becomes 1 due to accessing the
interface of the server services. The client invokes the client side proxy, thus its fan-out becomes
1 as well. The client side proxy sends a request to the broker component, therefore, both its fan-in
and fan-out become 1. The broker component sends the request to the server side proxy. On the
other hand, the broker invokes the server to get informed of the interface of the server services.
Therefore, both fan-in and fan-out of the broker become 2. The server side proxy has the fan-in
and fan-out equal to those of the client side proxy too. The complexity of server components is
considered similar to that of the client/server style, thus style complexity is obtained
from 274+ f 8 n .
H. Object-Oriented style. If, in average, the number of fan-in and fan-out of each class is
considered as fo, then the complexity of each class becomes fo4 and the complexity of style is
f o4 n o .
Table 4 shows the complexity formulas of SASs. Values of f and fo are considered as similar to
those in the Section 3.1.
Table 4. Complexity Formulas of SASs
Symbol
RPS
Complexity Formula
9 n
BKB
2
42 +36 n
P/F
n−2
LYD
I/I
C/S
BRK
OO
n−2
1
f4 n
274+ f 8 n
f o4 n o
By setting the parameters n and no, the complexity value of SASs is computed considering the
software size and its diagram is shown in figure 2. According to this diagram, the complexity
value of most SASs is increased by increasing of the software size.
9. Computer Science & Information Technology (CS & IT)
191
3.3. Measuring the Cohesion of SASs
In this section, the cohesion formula of every SAS is computed using (7) to (8).
A. Repository style. Each component processes the same set of data, so their cohesion type is
communicational. The repository component performs various functions on the data, and in each
calling, one of the functions is performed. So its cohesion type is logical, and the cohesion of
style is n c 2 + c12 .
2
Figure 2. Complexity value of SASs based on size of software
B. Blackboard style. Each knowledge resource processes the same set of data, so their cohesion
type is communicational. The control component invokes the knowledge resources based on the
status of the blackboard. Therefore, its cohesion type is logical. The blackboard component
performs various functions and, in each invocation, one of these functions is performed. So, its
2
cohesion type is logical, and the cohesion of style is n c 2 + 2 c1 .
2
C. Pipe and filter style. Each filter processes the same set of data, so its cohesion type is
communicational and the cohesion of style is n .c 2 .
D. Layered style. Each layer contains some components; regarding the invoking of upper layer,
one of components of the lower layer is performed, so the cohesion type of each layer is logical
and the cohesion of style is n .c1 .
E. Implicit invocation style. Since the components are publisher or interested in the event, their
cohesion type is communicational. The dispatcher component performs various functions and, in
each invocation, one of them is performed. Thus, its cohesion type is logical and the cohesion of
2
2
2
style is C1 + nC .
F. Client/Server style. The server provides various services for the client by its components, and
in each invocation, one or some of the server components are performed so that each one works
on the same data. Accordingly, their cohesion type is communicational. The client component
performs a specific function, so its cohesion type is functional. The repository component
10. 192
Computer Science & Information Technology (CS & IT)
performs various functions and in each calling, one of them is performed. So its cohesion type is
2
2
2
logical and the cohesion of style is C 1 + nC 2 + C 3 .
G. Broker style. The client side proxy, server side proxy, broker and server components perform
various functions and in each invocation, just one of the functions is performed, so their cohesion
type is logical. The client component performs a specific function, thus its cohesion type is
functional. The repository component performs various functions and in each calling, one of them
is performed. Therefore, its cohesion type is logical. Cohesion of the server components is
considered similar to that of the client/server style. Thus, the cohesion of style
is
4C
2
1
+ nC
2
2
+
2
C .
3
H. Object-Oriented style. The classes in this style define the data of an entity and its related
functions, so, the cohesion type of each class is communicational and the cohesion of style is
no .C2
.
Column 2 of Table 5 represents the cohesion formulas of SASs. The third column shows the
cohesion value obtained by replacing the weight of cohesion type based on Table 2. By setting the
parameters n and no, the cohesion value of SASs is computed considering the software size and
its diagram is shown in figure 3. According to this diagram, the cohesion value of SASs is
increased by increasing of the software size and the amount of increase is higher in the objectoriented style relative to the other styles.
Figure 3. Cohesion value of SASs based on the software size
11. Computer Science & Information Technology (CS & IT)
193
Table 5. Cohesion Formulas of SASs
Symbol
Cohesion Formula
2
Cohesion Value
2
4n + 1
RPS
n c2 + c1
BKB
n.C2 + 2C1
P/F
n . c2
2 n
LYD
n . c1
n
I/I
C1 + nC
2
C/S
C1
2
2
2
2
BRK
4C
OO
1+ 4n
2
+ nC
2
4n + 2
2
+ C3
2
2
2
10 + 4n
C
2
13 + 4n
no .C 2
1
+ nC
2
+
3
2 no
4. COMPUTATION OF THE RANK OF SASs
In this section, the ranking of SASs is performed based on the results of measurement coupling,
complexity and cohesion of SASs using AHP method.
4.1. Organizing Ranking Problem of SASs
In SASs ranking problem, aim is in the first level, metrics are in the second level and SASs are in
the third levels of the structure.
Figure 4. Hierarchical structure of SASs ranking
4.2. Computation of Priority of Metrics and the Relative Rank of SASs
In this stage, comparison matrix of the metrics and comparison matrices of SASs for the metrics
are formed. The complexity and cohesion values of a component do not affect on the other
components of SAS. However, the coupling value of a component affects the related components.
Accordingly and due to the emphasis of researches on the importance of coupling [13], [15] the
preference of coupling metric is considered more important than (1.6 ) the other metrics, and the
preferences of other metrics are considered equal. Then the relative priority of metrics is
computed by AHP method, the relative priority of coupling becomes 0.444 and that of the other
metrics become 0.278.
To determine the relative rank of SASs for each metric, comparison matrices of SASs for each
metric is formed. To set cell (i, j) of the comparison matrix of metric k, for the style x in row i
with the style y in column j, if there is a direct relation between the metric k and maintainability,
12. 194
Computer Science & Information Technology (CS & IT)
the ratio of the metric value of style x to the metric value of style y is set to cell (i,j), otherwise
the inverse of the ratio is set to cell(i,j). After setting of the comparison matrices based on the
described procedure, the relative rank of SASs for each metric is computed by AHP method.
Investigation of the consistency using the Expertchoice tool, tool of AHP method, showed that
consistency index is zero, so there is no inconsistency between the comparisons.
4.3. Computing the Final Rank of SASs
The final rank of SASs is computed regarding the priority of metrics and the relative ranks of
SASs. Table 6 shows the final rank of SASs. Based on the values of this Table, the Implicit/
Invocation (I/I), Pipe and Filter (P/F), and Layered (LYD) styles provide the highest support for
maintainability, respectively.
Figure 5 shows the changes in maintainability value of SASs based on the changes of software
size. With the increasing of software size, the rank of some styles such as Pipe and Filter(P/F) and
Layered (LYD) are decreased, and the rank of some styles such as Implicit Invocation(I/I) are
increased while the rank of some styles such as Blackboard(BKB) are not changed considerably.
Table 6. Rank of SASs from the maintainability viewpoint
Symbol
RPS
BKB
P/F
LYD
I/I
C/S
BRK
OO
n=3
no=21
64
52
187
185
223
95
87
107
n=4
no=28
67
54
176
169
238
97
89
110
n=5
no=35
69
54
170
161
246
97
91
112
n=6
no=42
69
55
166
155
251
98
92
114
n=7
no=49
70
55
163
151
255
99
94
115
n=8
no=56
70
55
160
149
257
99
94
116
n=9
no=63
70
55
158
146
260
99
95
116
Figure 5. Maintainability value of SASs based on the changes of software size
Figure 6 shows the diagram of styles ranks based on the relative priority of metrics. It is known as
sensitivity analysis diagram, which is drawn by Expertchoice. In this diagram, the vertical lines
show the relative priority of metrics and the horizontal lines show the rank of SASs based on the
metrics. The final rank of SASs is determined by the “OVERALL” label based on the vertical line
(figure 6). The coupling metric accords with the y-axes and after that are complexity, cohesion
and combination of the three metrics.
13. Computer Science & Information Technology (CS & IT)
195
Figure 6. Diagram of styles rank regarding the relative priority of metrics
4.4. Analyzing the Rank of SAS
Here, by changing the values of some parameters, the effects of these changes on the rank of
SASs are investigated.
•
•
•
•
For the values of coupling types (Section 2.A), other values were used besides the values
mentioned in table 1 (for twelve values in the ranges 1≤w1≤1.5, 1.5≤w2≤2.5 and
2.5≤w3≤3.5), but they did not lead to any changes in the rank position of the SASs'
maintainability.
For the values of cohesion types (Section 2.C), other values were used besides the values
mentioned in table 2 (for twelve values in the ranges 1≤c1≤1.5, 1.5≤c2≤2.5 and
3≤c3≤3.5), but they did not lead to any changes in the rank position of the SASs'
maintainability.
By changing the f parameter (coupling of the server components in Section 3.A) in the
range of 1.65≤ f≤2.8 at the Client/Server (C/S) style, the change in the rank position of
this style was checked. It was found that only for f≥2, the rank position of this style is
placed after the Broker (BRK) style and no other change in the rank position of other
styles was seen.
For determining the relative priority of metrics (In Section 4.B), in addition to 1.6 (the
relative priority of coupling metric compared to that of the other metric), the ten values in
the range of 1.3 to 2.2 were used. The results showed no changes in the rank position of
the styles from maintainability viewpoint.
5. CONCLUSION
In this study, a model was offered to analyze the impact of SASs on software maintainability
according to the measurement-based evaluation of SASs. In this model, first, the formulas were
presented to compute the coupling, complexity and cohesion values of each SAS. Next, the
coupling, complexity and cohesion values of SASs were computed quantitatively using the
presented formulas. Then, the relative rank of each SAS was determined regarding the coupling,
complexity and cohesion values of SASs. Afterward, the priority of metrics was determined.
Subsequently, the final rank of SASs maintainability was determined using AHP method.
The analyses done showed that our proposed method had stability regarding the value of coupling
types, different values of f parameter, value of cohesion types and preference of coupling metric
to the other metrics.
14. 196
Computer Science & Information Technology (CS & IT)
Since the evaluation of this paper is based on measurement as compared to the method used in
[9], which uses scenario-based evaluation and the quality of its results is dependent on the used
scenarios and also on the extensive expert participation, the results of our proposed model is more
precise, more reliable and more analyzable.
The proposed method gives formulas to determine the values of 1) coupling, 2) complexity and 3)
cohesion of each SAS, while this has not been done in previous methods.
As compared to [4], [8], both the proposed method and the method used in [9] give the
quantitative results about the maintainability of SASs that is basis of the systematic
recommendation and selection of SAS.
Finally, only the proposed method examines the effect of the software size on the maintainability
rank of SASs.
The methods given [6], [7], [11] use the mathematic model-based evaluation and the method used
in [10] uses the simulation-based evaluation. These methods verify specific features such as
consistency and satisfaction of some properties by SASs that are different from the quality
attributes required in this paper. The above points and table 8 clearly show the position of the
proposed method as compared to the methods of [4], [8] and [9].
It is worth noting that the ranking of SASs based on our proposed method is consistent with the
priorities of SASs from the viewpoint of maintainability in the methods used in [2], [12], which
are based on experimental studies.
Table 7. Comparison of the proposed method with the related methods
Method
Proposed
Method
Criteria
Base
Offering the Quantitative Results
about the Maintainability of SASs
Total SASs that were Investigated
Considering the Effect of Software
Size on the Rank of SASs
Measurement
●
8
●
Method
[4]
Tree
Method
[8]
Method [9]
Unsystematic
Scenario
●
6
8
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
Len Bass, Paul Clements. & Rick Kazman(2003) Software Architecture in Practice (2nd Edition),
Addison-Wesley, p 89.
F. Buschmann, R. Meunier, H. Rohnert, P. Sornmerlad, & M. Stal,(1996) Pattern-Oriented Software
Architecture- A system of Patterns" John Wiley & Sons, p. 394.
C. Seo, G. Edwards, S. Malek, & N. Medvidovic,(2009) "A Framework for Estimating the Impact of
a Distributed Software System’s Architectural Style on Its Energy Consumption", 7th Working
IEEE/IFIP Conf. on Software Architecture, pp. 277-280.
B. Harrison, & P. Avgeriou,(2007) "Leveraging Architecture Patterns to Satisfy Quality Attributes",
1st European Conf. on Software Architecture, Springer, pp. 263-270.
P. Avgeriou P, & U. Zdun, (2005) "Architectural Patterns Revisited: A Pattern Language", Proc. of
10th European Conf. on Pattern Languages of Programs, pp.1-39.
J.S Kim, and D. Garlan, (2006) "Analyzing Architectural Styles with alloy", Proc. of the ISSTA 2006
workshop on Role of Software Architecture for Testing and Analysis, pp. 70-80.
R. Bruni, A. Bucchiarone, A. Gnesi, D. Hirsch, & A.L. Lafuente, (2008) "Graph-based Design and
Analysis of Dynamic Software Architectures", LNCS 5065, pp. 37–56,.
15. Computer Science & Information Technology (CS & IT)
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
197
H. Reza, & E. Grant, (2005) "Quality-Oriented Software Architecture", the IEEE Int. Conf on
Information Technology, pp. 140 – 145.
Gholamreza Shahmohammadi, & Saeed Jalili, (2009) "Scenario-Based Quantitative Evaluation of
Software Architecture Style from Maintainability Viewpoint", 14 th Annual of CSI Computer
Conference (CSICC 2009), Iran, Amirkabir University.
H. Grahn, & J. Bosch, (1998) "Some Initial Performance Characteristics of Three Architectural
Styles", Proc. of Int. Workshop on Software and Performance.
D. Garlan, & S. Khersonsky, (2000) "Model Checking Implicit Invocation Systems", 10th Int.
Workshop On Software Specification and Design.
M. Shaw & D. Garlan, (1996) Software Architecture: Perspectives Discipline on an Emerging
Discipline, Prentice Hall.
L. Briand, S. Morasca, & V. Basili, (1996) "Property Based Software Engineering Measurement",
IEEE Trans on Software Eng., vol. 22, no. 1, pp. 68-86.
L. Briand, J. Wust, & H. Lounis, (1999) "Using Coupling Measurement for Impact Analysis in
Object-Oriented Systems", IEEE Int. Conf. on Software Maintenance.
S.L. Pfleeger, & J.M. Atlee, (2006) ”Software Engineering, Theory and Practice”, 3rd Edition,
Prentice Hall.
P. Yu, T. Systa, & H. Muller, (2002) "Predicting Fault Proneness using OO Metrics. An Industrial
Case Study," 6th European Conf. on Software Maintenance and Reengineering, pp.99 – 107.
M. Alshayeb, and L. Wei, (2003) "An Empirical Validation of Object-Oriented Metrics in Two
Different Iterative Software Processes," IEEE Trans on Software Engineering, vol. 29 (11), pp. 1043
– 1049.
F. Bachmann, L. Bass, M. Klein, M. & C. Shelton, (2005) “Designing Software Architectures to
Achieve Quality Attribute Requirements”, IEE Proc. of Software, Vol. 152, No 4,pp. 153- 165.
C.L. Hwang, K. Yoon, (1981) "Multiple Attribute-Decision Making", Springer-Verlag.
T. L. Saaty, & L. G. Vargas, (2001) “Models, Methods, Concepts & Applications of the Analytic
Hierarchy Process”, Kluwer Academic Publisher.
L. Bass, P. Clements, & R. Kazman, (1998) Software Architecture in Practice, Addison-Wesley, p.
17.
ISO, (2001), International Organization for Standardization, “ISO 9126-1:2001, Software Engineering
– Product quality, Part 1: Quality model”.
E. Yourdon, & L. Constantine, (1978) Structured Design, Englewood Cliff, NJ, prentice Hall.
N. Fenton, & A. Melton, (1990) "Deriving Structurally Based Software Measures", Journal of
Systems and Software 12(3), pp. 177-187.
M. J. Shepperd, & D.C. Ince, (1990) "The use of metrics in the early detection of design errors",
Proc.of the European Software Engineering Conf, pp.67-85.
NE. Fenton, & SL. Pfleeger, (1997) "Software Metrics: A Rigorous and Practical Approach", (2nd
Edition), International Thomson Computer PRESS.
S. Chidamber, & C. Kemerer, (1994) "A Metrics Suite for Object Oriented Design", IEEE Trans on
Software Engineering, vol. 20, pp. 476-493.
L. Yu, & S. Ramaswamy,(2007) "Component Dependency in Object-Oriented Software", Journal of
Computer Science and Technology, 22(3), pp. 379-386.
Lee, S.hyun. & Kim Mi Na, (2008) “This is my paper”, ABC Transactions on ECE, Vol. 10, No. 5,
pp120-122.
AUTHORS
Gholamreza Shahmohammadi received his Ph.D. degree from Tarbiat Modares
University (TMU, Tehran, Iran) in 2009 and his M.Sc. degree in Computer
Engineering from TMU in 2001. Since 2010, he has been Assistant Professor at the
Olum Entezami University-Amin(Tehran, Iran). His main research interests are
software engineering, quantitative evaluation of software architecture, software metrics
and software cost estimation.
E-mail: Shah_mohammadi@yahoo.co.uk