DSpace - Tor Vergata >
Facoltà di Ingegneria >
Tesi di dottorato in ingegneria >
Please use this identifier to cite or link to this item:
Full metadata record
|description.abstract||L'architettura software è emersa come una importante tematica, nel campo del software engineering, per gestire la complessità relativa allo sviluppo e manutenzione di grandi sistemi software.
L'idea chiave di questa tesi è che non c'è alcuna soluzione miracolosa nell'ambito del software engineering ma ogni tecnica ha i suoi vantaggi e svantaggi; di conseguenza, la bontà di un determinato metodo varia in base alle caratteristiche del contesto di applicazione.
Un famoso proverbio dice: 1)un cattivo artigiano incolpa i suoi strumenti, 2) il peggior artigiano sceglie lo strumento sbagliato e poi da colpa allo strumento, 3) un buon artigiano sceglie ed usa gli strumenti in maniera opportuna. Mentre la comunità del software engineering si è occupata prevalentemente di offrire sempre nuovi metodi il cui utilizzo è supposto dare dei risultati migliori dei precedenti, c'è un vuoto nell'assistere l'architetto del sistema software nel selezionare o mettere a punto il giusto metodo. In questo contesto, la presente tesi offre un insieme di strumenti per la progettazione dell'architettura software, dal quale l'architetto di sistema è agevolato a selezione (e mettere appunto) il miglior strumento da utilizzare in base alle peculiarità del contesto di applicazione.
Progettare una architettura software è un'attività molto complicata e involve differente tipologie di attività; la presente tesi riguarda le seguenti attività: metodi di progettazione dell'architettura software; tecniche decisionali per giungere a compromessi durane la progettazione dell'architettura software; strategie per applicare studi empirici sui metodi di progettazione architetturale; strategie di documentazioni delle decisioni progettuali||en|
|description.abstract||Software architecture has emerged as an important field of software engineering for managing the realm of large-system development and maintenance. The main intent of software architecture is to provide intellectual control over a sophisticated system enormous complexity. The key idea of this dissertation is that there is no silver bullet in software engineering, each method has pros and cons; the goodness of a method (tool, technique, etc.) varies based on the peculiarities of the application context.
According to a famous idiom: i) a poor craftsman blames his tool, ii) a really bad craftsman chooses the wrong tool for the job and then he blames the tool, iii) a good craftsman chooses and uses the tool well. While the software engineering community has been mainly focused on providing new methods, which usage are aimed/supposed to provide better results than older methods, there is a lack in helping the software practitioners in selecting/adapting the available tools. Hence, in this view, the contribution of the present dissertation, instead of being a new method for architectural design, which would have been easily forgotten in a bookcase, is a characterization of the existing methods. In other words, this dissertation provides a toolbox for software architecture design, from which software architects can select the best method to apply, according to the application context.
In this dissertation, the available architectural methods have been characterized by means of empirical studies. Unfortunately, the application of empirical methods on software architecture includes some troubles. A contribution of the present dissertation is a characterization of the available empirical methods by exposing their levels of challenges that researchers have to face when applying empiricism to software architecture. Such a proposed characterization should help to increase both the number and validity of software architecture empirical studies by allowing researchers to select the most suitable empirical method(s) to apply (i.e. the one with minor challenges), based on the application contexts (e.g. available software applications, architects, reviewers). However, in our view, in order to provide high levels of conclusion and internal validity, empirical methods for software architecture should be oriented to take advantage of both quantitative and qualitative data. Moreover, based on the results from two experiments, the challenges, in conducting evidence-based software architecture investigations, might 1) highly influence the results of the empirical studies, and 2) be faced by empiricistsâ cleverness.
Architecting software system is a complex job and it encompasses several activities; this dissertation focuses on the following families of activities: software architecture design, resolving architectural tradeoffs, documenting design decisions, and enacting empirical studies on software architecture (as just described).
Regarding the resolution of architectural tradeoffs, based on our review of already proposed decision making techniques, we realized that no one of the available decision-making technique can be considered in general better than another; each technique has intrinsically its own level of complexity and proneness to specific problems. Since we cannot decide in advance what degree of complexity of modeling is sufficient, instead of proceeding by trial and error, we offered guidelines on which complexity to emphasize for avoiding specific problem(s). Our key idea is to expose and organize in a useful way, namely by a characterization schema, in what extent each decision-making technique is prone to specific problems. In this way, the level of proneness of specific technique to specific problems becomes a quality attribute of the decision-making technique. Furthermore, we situated in the proposed characterization schema eighteen different decision-making techniques already proposed by the literature in the domains of architecture design, COTS selection, and release planning. Such localization validates the completeness of the proposed characterization schema, and it provides a useful reference for analyzing the state of the art
Regarding software architecture design, this dissertation tried to answer to following question: "Do actual software architecture design methods meet architects needs?" To do so, we provide a characterization of the available methods by defining nine categories of software architectsâ needs, proposing an ordinal scale for evaluating the degree to which a given software architecture design method meets the needs, and then applying this to a set of software architecture design methods. Based on results from the present study, we argue that there are two opposite but valid answers to the aforementioned question: a) Yes, they do. In fact, we showed that one or more software architecture design methods are able to meet each individual architect needs that we considered. b) No, they do not. In fact, we showed that there is no software architecture design method that is able to meet any tuple of seven or more needs, which means that there is still some work to do to improve software architecture design methods to actually help architects. In order to provide directions for software architecture design method improvement, we presented couples of needs, and triplets of needs that actual software architecture design methods are unable to meet. Moreover, an architect can use such characterization to choose the software architecture design method which better meets his needs.
Regarding design decision documentation, we conducted a controlled experiment for analyzing the impact of documenting design decisions rationale on effectiveness and efficiency of individual/team decision-making in presence of requirement changes. Main results show that, for both individual and team-based decision-making, effectiveness significantly improves, while efficiency remains unaltered, when decision-makers are allowed to use, rather not use, the proposed design rationale documentation technique. Being sure that documenting design-decisions rationale does help, we argued why it is not used in practice and what we can do to facilitate its usage. Older design decisions rationale documentation methods aimed at maximizing the consumer (documentation reader) benefits by forcing the producer (documentation writer) to document all the potential useful information; they eventually ran into too many inhibitors to be used in practice. In this dissertation we propose a value-based approach for documenting the reasons behind design decision, which is based on a priori understanding of who will benefit later on, from what set of information, and in which amount. Such a value-based approach for documenting the reasons behind design decision offers means to mitigate all the known inhibitors and it is based on the hypothesis that the set of required information depends on the purpose (use case) of the documentation. In order to validate such a hypothesis we ran an experiment in a controlled environment, employing fifty subjects, twenty-five decisions, and five different purposes (documentation use case) of the documentation. Each subjects practically used the documentation to enact all the five documentation use case(s) by providing an answer and a level of utility for each category of information in the provided documentation. Both descriptive and statistical results confirm our expectancies that the level of utility, related to the same category of information in the design decision rationale documentation, significantly changes according to the purpose of the documentation. Such result is novel and implies that the consumer of the rationale documentation requires, or not, a specific category of information according the specific purpose of the documentation. Consequently, empirical results suggest that the producer can tailor the design decision rationale documentation by including only the information required for the expected purposes of the documentation. This result demonstrates the feasibility of our proposed value-based approach for documenting the reasons behind design decision.||en|
|description.tableofcontents||1. Introduction - 1.1 Research objective and approach - 1.2 Dissertation outline - 1.3 Overview of research domain - 1.3.1 Software Architecture - 1.3.2 Software architecture design - 1.3.3 Design decision rationale documentation - 2. A characterization of empirical software engineering methods in being applied on software architecture - 2.1 Introduction - 2.2 Empirical software engineering and software architecture: detecting cultural misalignments - 2.3 Ten challenges in applying empirical software engineering to software architecture - 2.3.1 Defining software architecture âgoodnessâ - 2.3.2 Describing a software architecture evaluation technique - 2.3.3 Selecting the software architecture evaluation input - 2.3.4 Describing the software architecture evaluation scenarios - 2.3.5 Describing the software architecture evaluation results - 2.3.6 Evaluating software architecture without analyzing also the resulting system - 2.3.7 Affording the cost of professional reviews - 2.3.8 Adopting a complex system as experiment object - 2.3.9 Defining the boundaries of software architecture - 2.3.10 Affording the cost of experienced subjects - 2.4 Characterizing empirical methods with respect to software architecture - 2.4.1 Real ongoing project - 2.4.2 Completed real project - 2.4.3 Ad-hoc project - 2.4.4 Challenges in synthesis - 2.5 Our experiences - 2.5.1 Impact of the Boundary-Control-Entity architectural pattern - 2.5.2 Impact of the Design Decision Rationale Documentation - 2.6 Conclusion - 3. A characterization of software architecture design methods - 3.1 Introduction - 3.2 Context and background - 3.2.1 Survey of software architecture design methods - 3.2.2 Software architecture design methods - 3.3 Rationale of our approach - 3.4 Architects seeds - 3.4.1 Abstraction and refinement - 3.4.2 Empirical validation - 3.4.3 Risk management - 3.4.4 Interaction management - 3.4.5 Tool support - 3.4.6 Concerns - 3.4.7 Knowledge base - 3.4.8 Requirements change management - 3.4.9 Number of supported activities - 3.5 Architects needs and methods not taken into consideration - 3.6 Results and comments - 3.6.1 Introduction, limits and threats to validity - 3.6.2 Reference for helping an architect to select the SADM mostly appropriate for the needs - 3.6.3 Areas of improvement in SADMs - 3.7 Conclusion and future work - 3.8 Acknowledgements. - 4. Resolving tradeoffs in architecture design: a characterization schema of decision-making techniques - 4.1 Introduction - 4.1.1 Context and motivation - 4.1.2 Contribution - 4.1.3 Scope - 4.1.4 Vocabulary - 4.1.5 Structure - 4.2 Related work - 4.3 The proposal - 4.3.1 Key idea - 4.3.2 Approach - 4.3.3 Limitations - 4.4 Troubles in decision-making - 4.4.1 Attribute interpretation - 4.4.2 Solution properties misunderstandings - 4.4.3 Managing stakeholders effort - 4.4.4 Solution selection - 4.4.5 Stakeholders disagreement - 4.5 Components of the characterization schema - 4.5.1 Attribute identification - 4.5.2 Need modeling - 4.5.3 Type of fulfillment description - 4.5.4 Risk description - 4.5.5 Time for expressing the issue - 4.6 Characterization schema - 4.7 Software engineering current practice - 4.8 Open problems in multi attribute decision-making - 4.9 Suggestions - 4.10 Conclusion. - 5. Assessing the importance of documenting design decision rationale - 5.1 Introduction - 5.2 Study motivation and research hypotheses - 5.3 Related work - 5.3.1 Empirical evaluation of Design Decision Rationale - 5.3.2 Cooperation - 5.3.3 Agility - 5.4 The DDRD DGA technique - 5.4.1 Expected effects on collaboration - 5.4.2 Expected effects on agility - 5.5 Experiment planning and operation - 5.5.1 Experiment definition and setting - 5.5.2 Training - 5.5.3 Subjects - 5.5.4 Objects and materials - 5.5.5 Factor and parameters - 5.5.6 Dependent variables - 5.6 Experiments results and data analysis - 5.6.1 Data set reduction - 5.6.2 Descriptive statistics - 5.6.3 Hypotheses testing - 5.7 Result discussion - 5.7.1 Individual decision-making - 5.7.2 Team decision-making - 5.8 Threats to validity - 5.8.1 Conclusion validity - 5.8.2 Construct validity - 5.8.3 Internal validity - 5.8.4 External validity - 5.9 Conclusion and future works. - 6. A value-based approach for the documentation of design decision rationale: principles and empirical feasibility study - 6.1 Introduction - 6.2 Study motivation - 6.2.1 Value-based software engineering - 6.2.2 Design decision rationale documentation - 6.2.3 Related works - 6.3 A value-based approach for documenting design decision rationale - 6.3.1 Rationale - 6.3.2 DDRD Use-cases - 6.3.3 Key idea - 6.3.4 Process - 6.3.5 Expected advantages - 6.4 Empirical feasibility study - 6.4.1 Experiment process description - 6.4.2 Experiment Result Description - 6.5 Conclusion and future work. - 7. Conclusion. - 8. References||en|
|subject||ingegneria del software||en|
|subject||ingegneria del software basata sull'evidenza||en|
|subject||documentazione delle decisioni progettuali||en|
|title||A Toolbox for software architecture design||en|
|title.alternative||Un Insieme di strumenti per la progettazione architetturale di sistemi software||en|
|degree.name||Dottorato in informatica e ingegneria dell'automazione||en|
|degree.discipline||Facoltà di ingegneria||en|
|degree.grantor||Università degli studi di Roma Tor Vergata||en|
|Appears in Collections:||Tesi di dottorato in ingegneria|
Files in This Item:
|abstract Inglese e Italiano.pdf||Abstract||28Kb||Adobe PDF||View/Open|
|TesiA5 v8.pdf||Tesi||1665Kb||Adobe PDF||View/Open|
Show simple item record
All items in DSpace are protected by copyright, with all rights reserved.