Software architecture designing evaluation methods evaluation and study

Software architecture designing evaluation methods evaluation and study

Master of Software Engineering Student Islamic Azad University of Saveh, Computer Science

Department

Email: AsadzdehNilufar@gmail.com ABSTRACT

In this article we discussed about the software architecture designing as one of the newest research pillars in software engineering. There are many different methods for software evaluation. In this article we present a complete evaluation about software different method as: SPE, EBAE, SAM, LQN, ARGUS-I, ALMA, ATAM, and SAAM and introduced a proper categorization to compare the software architecture designing evaluation. This format presented by the purpose of similarities and differences discovery between architecture designing evaluation method. Therefore in this article we decide to evaluate features related to software structure designing evaluation method mentioned above and present a framework to categorize and compare them.

Key terms: software architecture, evaluation software engineering,requirements 1- INTRODUCTION:

In recent year researches about software architecture has changed to one of the important issues in software engineering. Because software architecture effects on the system quality features as practicality, maintenance and other issues, therefore taken decisions during architecting has influential effect on the system results. Today software architecture as a solution is considered for high level designing. Architecture is made based on a collection of inquires which should be obviated. This inquiry gathered from beneficiaries like system applicants and developers. Any attempt to present complete framework for categorization and software evaluation method comparison needs past researchers' studies and research results. We try to evaluate all software architecture evaluation method. It is necessary to say that unfortunately most of published articles in this field had not presented a clear format about methods comparison and mostly these methods are published to support an evaluation method development. The software engineering society has presented different methods ofsoftware architecture evaluation but few works has been presented about methods comparison in systematic way and discovery of similarities and differences exist in these methods. One of the activities performed in this field is presentation of a framework in which it has tried to compare architecturalevaluation methods which based on this framework 8 samples format from software architecture evaluation methods on the basis of evaluation techniques, quality features and software architecture description, the beneficiaries involvement in evaluation process, the method activitiesand the capability to reuse present knowledge station application and validity assessment of comparison method have been evaluated. Regardless of this fact this task has its own problems for example writers have not presented any precise description about their format element

186

selection and did not declare their reasoning clearly. We believe that an evaluation method should present more features, 1. In presented framework[2], writers only evaluated 3 methods and in addition to comparison framework they don't include some important features as architecture definition, architecture description, supporting tools and etc., that an evaluation method should be capable to cover these features. In performed evaluation in 3 a method for software architecture evaluationwith considering to ontology has been presented.Software production linemakesnew inquiries for architecture evaluation methods which is reflected in the comparison framework. The main aim of evaluation in 4 is to present criterions for an important evaluation method and to compare available evaluation methods these criterions are; realization of targets, conditions and concentration on under evaluating features from analysis to determination of results evaluation. In 5 more completed comparison framework for discovery of similarities and differences available in 11 samples of software architecture evaluation methods suggested which includes more features, unfortunately it is not capable to support most of software architecture evaluation methods and only in this framework the architectural evaluation method were analyzed based on the evaluating scenario.

2- Software architecture

Software architecture presents a high level abstraction about software systems to element form, connections and course-grainprocessors and their configuration. Actually software architecture connects the software systems organization by the use of criterions and relations in a system and describes data between criterions and connection. The main concentration in software architecture isto improve the software development because architectural models could realize the structural, behavioral and complicated aspects of software and present them officially, thereforepresentthe precise reasoning about the total features,but in addition to understanding total features whose target is to realize the architectural solutions is an engineering method for models and theories for the continuous issues solution. These models and theories lead to edition of successful experiences that could be performed for similar problems solving. Now the software architecture is the combination of architectural elements and external features and internal connections between them. Next point that exist in software realization is the categorization of elements it means that they make a leveled structure of elements and relations but it might that we present some different structures for example in great scales projects, different elements are divided between different teams. Imagine that for such activity we divide the system practically between the team and for another time we divide it as data forother teams, therefore we will have different structures for a system description. Finally the structures architectures are indented in a system that these structures are the architectural elements and only will be between their external behavior and features of each element and external relation.

Table 1: a framework for software architecture definitions

Logic for elements selection Software architectur al elements relation Each elements features and behaviors Software architectur al elements Software architectur al structure row

187 Software elements interrelation Software elements external feature Software elements System structure or structures 1 The completion and designing dominant principals The relation between criterions- criterion relation with environment criterions A system thorough organization 2 Structural elements selection Combination of behavioral and structural elements Elements each external behaviors- structural elements intermediate Structural elements A system organizing important decisions 3 Dominant principals in designing and completion Relation between criterions Architectura l elements including process elements- data elements and connecting elements A system criterion structure 4 Rules and regulations for system Subsystems and criterions relation and cooperation Elements features Subsystems- software criterions 5 Criterions connections Each criterion behavior- each criterion intermediate Behavioral and functional criterions An abstract system 6 The system logic and principals Connections between criterions The system beneficiaries inquiries- criterions 7 System maintenanc Software structures Software criterions Software structures 8

188 e and developmen t directions and principals communicati on designing important decision Contracts- policies- regulations dominant on their relation Subsystems and criterions relation Criterions and subsystems combination mechanism Criterions and subsystems Stable framework- one skeleton 9 Regulation on criterions- a logic for their selection External relations between criterions Practical criterions Base framework – an abstract system 10

2-1 Software architecture designing process

Software architecture designing process is the function that receives the inquiries as an input and presents an architectural design as output. This function is not an automatic process and it is affected by software architecture. The main phases in this designing are presented in the graph below;

Figure 2: software architecture designing process

The designing process begins with basic designs (architectural designing is based on inquires and duties predetermined in inquires documents). Although the software engineers don’t design

189

the system without the capability to be reused and confidencecapability, in this step the quality inquiries are not determined. The second phase is the software quality features evaluation according to quality inquiries. Each quality feature presents an assessment by the use of quality and quantity techniques. If all assessments about quality features are better or worse than expected condition, the architecture design process completed. Despite this fact the third phase of software architecture which is its changing is necessary. The third phase of architecturaldesigning includes designingsolution for quality features improvement. Each changing combination is fulfilled in the software architecture. This design is reconsidered and designing completed up to the time of all inquiries provided or architect decides that thereis no other proper solution and it is repeated. This situation needs that the customer again negotiate about inquiries, changes in quality features improvement solutions might have negative effects on some of quality features positively and in some negatively

3the software architecture evaluation

The software architecture has important role in software system life cycles. Therefore we should effectively evaluate the software. The architecture evaluation is done in one or some steps through the software development. The purpose of a software architecture evaluation is to realize risks and weak and strength points during primary steps. We can divide the software evaluation method in to four categorizations. 6

3-1- the methods based on experience

The methods which are based on previous experiences and knowledge are developing. In this method people based on previous experiences could claim whether the software architecture is proper adequately or not.

3-2- the methods based on simulation:

Methods which are based on the software architecture high level simulations from one or some criterions. These simulations could be applied for quality features evaluation as practicality and architectural validity.

3-3-methods based on modeling:

Mathematical modeling from mathematical proofs for practical quality features like practicality and capability of criterions security insurance are sued in architecture.

3-4-methods based on the scenario inquire

The architectural evaluation based on the scenario tries to evaluate especial quality features that this work performed by making scenario which describes the reality and tangible inquiries, 7. Some samples of evaluation methods based on the scenario are: software architectural method, architectural balancing point analysis, correction capability analysis method in architecture level.

4- Software architectural evaluation method

190

It is the architectural evaluation method based on the scenario. The main purpose of this method is to evaluate the validity of hypothesis and regulations in architecture basis toward documents that describe a practical program proper feature and in addition to architectural risk evaluation and concentration on critical points mainly focus on the architectural analysis method on the basis of scenario of variability comparison in organization different architecture software. This method applied for architecture or comparing some architecture and it has changed to a construction method to evaluate software architecture on the basis of completed scenario and according to the type of scenarios made during the evaluation process different quality features are covered by this method. The architectural analysis method based on the scenario applied in some studies.

4-2- The architectural equilibrium points analysis method

In architectural equilibrium points analysis method the evaluation made through scenario. The purpose of this method actually is to present a regular method to realize the software architecture capability in comparing 4 phases which are gathering inquiries and scenarios, fulfillment of scenarios and architectural views and model fabrication and analysis and transactions. The architectural analysis points have been used in many studies.

4-3- the correction capability analysis method in architectural level

In this method 8, the architectural evaluation is performed based on the scenario. The main aim of this method is to present a view of manufacturing for evaluation of maintenance capability to predict the costs and risk analysis and comparing two or some architecture. This method has been founded based on the architectural analysis method. This method present more accurate description about involving steps in the process compared to software architectural analysis and also in studies made by many writers it is confirmed and applied. This method contains 5 steps; determination of evaluation purposes, software architecture description, and deduction of some related scenarios, scenarios evaluation, results interpretation.

4-4- the ARGUS-I method

It is the method based on the features and this method is capable of structural analysis and architectural elements static and active behaviors. ARGUS-I uses the software architecture official description and its performance and graphs of each criterion behavior and the described architecture is evaluated in its practicality. In this method the architectural practicality assessed based on the number of recalling. This method as we know only has been used by its writers. 4-5- The Layered Queuingnetworks method

The Layered Queuingnetworks models are really popular and to evaluate them different systems are applied. Many writers suggested its application for the software practicality evaluation. AQueuing network model usually is evaluated by the use of simulation technique. This method is based on the architectural transformation to a Layered Queuingnetwork model that the model describes the cooperation between the architectural elements and the processing time is necessary for each of cooperation. In this method as more our model is minor and more

191

accurate; the simulation is more complete and correct. The main purpose of Layered Queuingnetwork is to software architecture evaluation.

4-6 The SAM method:

It is a systematic method for software architecture analysis. The SAM method is to evaluate the system validity and practicality. This method follows two purposes, the first aim is to define the software and its features accurately and official analysis by use of official methods in addition to this SAM supports a software architectural feature which is applicable in time logic and Petri network. The second aim is to facilitate the software architectural analysis by the use of architectural hierarchy. This method as far as we know has been used by writers.

4-7- architectural analysis based on the experiment

The main process steps are: selection of prospect for evaluation, metering selection and definition, gathering metrics, architectures comparison and evaluation. The main purpose of this method evaluation is new system maintenance capability compared to previous version. 4-8- software performance engineering

The main purpose of software performance is to evaluate the practicality. This method could be applied for metrics practicality evaluation as response time, operational power, sources consumption and realization of gorges. The software architecture elements model and its cooperation are modelized and also predict the practicality without the hardware source entanglement. The software performance model produces input parameters for system performance. The system performance model is from the hardware model which is evaluated by the mathematical methods or simulations.

5- Comparison and evaluation

As mentioned in previous part, unfortunately few studies performed about the software architecture analysis method and its methods categorization, 9, 10. We tried in this article to present a framework for the similarities and differences between the evaluation methods that includes features which are supported by many available evaluating methods. We used other resources like wide studies in the field of software architecture, previous comparison framework, software engineers' discoveries analysis to select our framework. Before description of each framework element we present a definition about one of the most important concepts in software architecture and quality features.

Describing the term architecture is not a simple task, maybe it is the proof that there are many definitions which are presented in this field, although many definitions have common features, still there is no agreement on a standard definition. We use the definition presented by BEY and coworkers" software architecture for a program or a calculation system is that system structures that includethe software elements and visible specifications of each element and their relations."

The quality features, a software unnecessary inquiries like insurance capability, practicality, the capability to use and etc. according to the software quality it presents a quality that shows the features quality which is the proof of software special features proper combination. The quality inquires that should be provided by the software architecture usually are divided in to

192

two groups; the operational and development quality inquiries which are significant in proper performance if developers like maintenance capability which prioritize system from the applicants view like the application capability and practicality. In table 2 a summary of software architecture evaluation method presented in the form of comparison. Also a brief description has been given for each of elements in addition to the application logic in the framework.

Table 2:a framework for software architecture definitions

SPE EBA E LQN SAM ARG U S-I ALM A ATA M SAA M criteri ons Dorm ant Dorm ant Refine ment/ Dorm ant Dorm ant Refine ment/ Refine ment Refine ment/ Dorm ant Matur ation step Not prese nted Not presen ted Devel opme nt Not presen ted Not presen ted Devel opme nt On the applic ant duty On the applic ant duty definit ionSA - - - - - Comp letely covere d Not clearl y menti oned Suppo rt of proces s - 4 activit ies - - - Not presen ted 9 activit ies in 2 phases 6 activit ies The metho d activit ies Practi cality analy sis Syste m maint enanc e practi cality analys is - Syste m validit y and practi cality evalua tion Archit ecture analys is in practi cality and validit y depen dence Under correc tion Balan cing and sensiti ve points analys is Risk analys is The metho d targets practi cality Maint enanc e Softw are archit ecture practi cality practi cality 5 activit ies in order variou s Basica lly the changi ng Qualit y featur e

193 capabi lity practi cality evalua tion capabi lity - - practi cality - - Chang ing effect analys is, protec ting capabi lity predic tion Durin g the design ing phase Durin g the operat ion attribu tion to repetit ious proces s modul e after the SA design ing The metho d perfor mance step - - - - - Maint enanc e capabi lity Modul es views, physic al, applic ant, the data flow, proces s Logic al view and modul es Archit ecture descri ption Based on simul ation/ mathe matic al model izatio n Based on experi ence and criteri ons - Based on simula tion Based on simula tion - Based on scenar io Based on scenar io Evalu ation views

194 - Based on simula tion and mathe matica l model izatio n - - Separ ate from the archit ecture descri ption All of benefi ciary people All of benefi ciary people Benefi ciaries ' partici pation - It is not evalua ted - It is not evalua ted It is not evalua ted Based on scenar io It is presen ted enoug h Proble m are briefly descri bed None techni cal issues suppo rt It is not evalu ated It is not valida ted It is evalua ted It is not valida ted It is not valida ted In differe nt activit ies It is valida ted contin uously It is valida ted in variou s fields The metho d validit y assess ment It is not valida ted Not availa ble - Not availa ble Not availa ble It is nor clearl y menti oned A store advise d firmly for protec tion Not availa ble Reusi ng capabi lity Not availa ble Not specifi ed Not availa ble Not specifi ed Not specifi ed It is valida ted in variou s fields Begin ning and end prepar ation The begin ning and end strateg ies Requi red resour ces Not specif ied Just one item Not specifi ed Just one item Just one item Not availa ble Differ ent items Differ ent items The metho d applic

195 ation

cases 6-Conclusion

Because software architecture effects on quality feature of a system like practicality, security, maintenance capability and tec., therefore the taken decisions during architecting has influential effect on the system result, the main purpose of this article is categorization and comparison of architecture evaluation of software. This framework shaped by the purpose ofsimilarities and differences discovery between the available architecture evaluation methods. We also proved that the suggestive framework could be applied for realization of important features that an evaluation proper method could present. We don't proclaim to prepare a complete list of features that acomparison framework should have, rather we expect that this framework is repaired in future and developed. Briefly we can name below issues as future purposes, increase of researches on software evaluation methods which could consider some quality features, increase of investigations on evaluation methods which are applied frequently by researchers and confirmed. Presentation of a comprehensive comparison framework could support most of software architectural evaluation.