Get (Ebook) Agile Processes, in Software Engineering, and Extreme Programming: 16th International Conference, XP 2015, Helsinki, Finland, May 25-29, 2015, Proceedings by Casper Lassenius, Torgeir Dingsøyr, Maria Paasivaara (eds.) ISBN 9783319186115, 3319186116 PDF ebook with Full Chapters Now
Get (Ebook) Agile Processes, in Software Engineering, and Extreme Programming: 16th International Conference, XP 2015, Helsinki, Finland, May 25-29, 2015, Proceedings by Casper Lassenius, Torgeir Dingsøyr, Maria Paasivaara (eds.) ISBN 9783319186115, 3319186116 PDF ebook with Full Chapters Now
com
DOWLOAD EBOOK
ebooknice.com
ebooknice.com
https://ebooknice.com/product/sat-ii-success-
math-1c-and-2c-2002-peterson-s-sat-ii-success-1722018
ebooknice.com
ebooknice.com
(Ebook) Cambridge IGCSE and O Level History Workbook 2C -
Depth Study: the United States, 1919-41 2nd Edition by
Benjamin Harrison ISBN 9781398375147, 9781398375048,
1398375144, 1398375047
https://ebooknice.com/product/cambridge-igcse-and-o-level-history-
workbook-2c-depth-study-the-united-states-1919-41-2nd-edition-53538044
ebooknice.com
Agile Processes,
LNBIP 212
in Software Engineering,
and Extreme Programming
16th International Conference, XP 2015
Helsinki, Finland, May 25–29, 2015
Proceedings
123
Lecture Notes
in Business Information Processing 212
Series Editors
Wil van der Aalst
Eindhoven Technical University, Eindhoven, The Netherlands
John Mylopoulos
University of Trento, Povo, Italy
Michael Rosemann
Queensland University of Technology, Brisbane, QLD, Australia
Michael J. Shaw
University of Illinois, Urbana-Champaign, IL, USA
Clemens Szyperski
Microsoft Research, Redmond, WA, USA
More information about this series at http://www.springer.com/series/7911
Casper Lassenius · Torgeir Dingsøyr
Maria Paasivaara (Eds.)
Agile Processes,
in Software Engineering,
and Extreme Programming
16th International Conference, XP 2015
Helsinki, Finland, May 25–29, 2015
Proceedings
ABC
Editors
Casper Lassenius Maria Paasivaara
Aalto University Aalto University
Espoo Espoo
Finland Finland
Torgeir Dingsøyr
SINTEF
Trondheim
Norway
This volume contains the papers presented at XP 2015: the 16th International Con-
ference on Agile Software Development held during May 25–29, 2015 in Helsinki,
Finland.
While agile development already has become mainstream in industry, it is a field
that is constantly evolving and that continues to spur an enormous interest both in in-
dustry and academia. The XP conference series has, and continues to play, an important
role in bridging the academic and practitioner communities, providing a forum for both
formal and informal sharing and development of ideas, experiences, and opinions.
The theme of XP 2015 — Delivering value: Moving from Cyclic to Continuous
Value Delivery reflects the modern trend toward organizations that are simultaneously
very efficient and flexible in software development and delivery.
The XP 2015 program includes research papers, experience reports, industry and
practice sessions, scientific workshops, panels, lightning talks, technical demos, posters,
and a doctoral symposium. In total over all submission types, we received almost 300
proposals, showing that the XP community indeed is vibrant and active.
This proceedings volume contains the full research papers, short research papers,
and experience reports. In addition, we included the abstracts of select posters, extended
abstracts of the PhD symposium presentations, as well as the position statements of the
panel participants.
All of the submitted research papers went through a rigorous peer-review process.
Each paper was reviewed by three members of the Program Committee. We received
44 research papers, out of which 15 (34%) were accepted as full papers and 7 as short
papers.
We received 45 experience report proposals, out of which 11 (24%) were accepted
following the review process. Each accepted experience report proposal received the
guidance of an experienced shepherd in writing the final paper.
We would like to extend our thank you to all the people who have contributed to
XP 2015 and helped make it a success: the authors, the sponsors, the reviewers, the
volunteers, and the chairs. We hope you enjoy the conference!
Organizing Committee
General Chair
Maria Paasivaara Aalto University, Finland
Academic Chairs
Torgeir Dingsøyr SINTEF, Norway
Casper Lassenius Aalto University, Finland
Scientific Workshops
Daniela S. Cruzes SINTEF, Norway
Casper Lassenius Aalto University, Finland
Experience Reports
Rebecca Wirfs-Brock Wirfs-Brock Associates, USA
Ken Power Cisco Systems, Ireland
Technical Demos
Kari Systä Tampere University of Technology, Finland
Panels
Steve Fraser Independent Consultant, USA
Open Space
Charlie Poole Independent Consultant, USA
Doctoral Symposium
Peggy Gregory University of Central Lancashire, UK
Helen Sharp The Open University, UK
Posters
Andrey Maglyas Lappeenranta University of Technology, Finland
Ville T. Heikkilä Aalto University, Finland
Local Organization
Local Organizing Chair
Juha Itkonen Aalto University, Finland
Event Manager
Mary-Ann Wikström Aalto University, Finland
Web Masters
Ville T. Heikkilä Aalto University, Finland
Eero Laukkanen Aalto University, Finland
Organization IX
Sponsoring Institutions
Platinum Sponsors
Aalto University, Finland
Ericsson, Finland
Reaktor, Finland
Gold Sponsors
Nitor, Finland
Nokia, Finland
Omenia, Finland
Silver Sponsor
Agilefant, Finland
Contents
Short Papers
Experience Reports
Panels
Posters
Teaching Scrum – What We Did, What We Will Do and What Impedes Us . . . . 361
Emil Alégroth, Håkan Burden, Morgan Ericsson, Imed Hammouda,
Eric Knauss, and Jan-Philipp Steghöfer
1 Introduction
Different tools and techniques can be used for agile development. In our work, we
focus our attention on the development of a tool to select and suggest the best
refactorings of duplicated code. Duplicated code involves all non-trivial software
systems; the percentage of involved duplicated lines is usually estimated between
5 % and 20 %, sometimes reaching even 50 % [1,2]. Fowler [3] suggests that code
duplication is a bad smell and one of the major indicators of poor maintainability.
With the concept of “clone”we mean a code fragment duplicated in several
locations within a software system with several similarity degrees. We consider
“Cloning” as a synonym of “duplicating code”, both identifying the activity
of introducing clones of a code fragment within a software system. Anyway, a
shared definition of “similarity” does not exist, resulting in the lack of a rigorous
definition of clone [1,2]. Different types of cloned have been identified in the
literature, providing a clone classification involving the amount and the way a
code fragment is duplicated. The most commonly accepted classification is the
one of Roy et al. [4], which identifies four types of clones (we describe Type-1
and Type-3 of clones, the ones we detect through our approach, in Section 3.2).
c Springer International Publishing Switzerland 2015
C. Lassenius et al. (Eds.): XP 2015, LNBIP 212, pp. 3–14, 2015.
DOI: 10.1007/978-3-319-18612-2 1
4 F.A. Fontana et al.
The main problems related to code duplication are, e.g., the uncontrolled
spread of yet-to-know bugs, resulting in heavy correction time cost when discov-
ered, and heavy update time cost, when modification of an important part of a
code fragment implies modification of all duplicated fragments.
Even if duplication may not always be avoided, it is considered a serious
problem, mainly from a maintenance perspective. Many works investigated in
depth the factors causing its insertion, or provided taxonomies according to
several criteria and detection techniques, but just few works examined its man-
agement procedures [1]. Many sources suggest to fully delegate correction activ-
ities to developers’ experience and judgement [1,2], and assert the importance
of the “human in the loop” concept [3,5]. These assertions follow the aware-
ness that every modification to a software system must consider and respect the
design choices of that system. Furthermore, design choices are not easily cap-
tured within automated procedures. During duplicated code management, two
main decisional steps involve design aspects:
1. the choice of which instances are worth to be refactored and which are not,
2. the choice of which technique should be applied to remove a duplication
instance, once the instance has been evaluated as refactoring-worthy.
3 DCRA Approach
The main features characterizing our approach are the following:
– the extension of Golomingi’s [5] scenario set with further recurring locations,
– the analysis of the location of each clone pair, resulting in a specific set of
applicable refactoring techniques (see Tables 1 and 2),
– the ranking of the applicable refactoring techniques, based on a score weight-
ing different criteria,
– the aggregation of the information about clones and refactorings, on the
more critical clones, and on the best refactorings, according to numerical
criteria.
Table 2. DCRA locations and refactoring suggestions (remaining locations have only
the LU suggestion)
common external class, i.e., a class belonging to external libraries. This addition
is significant; in fact, our dedicated analysis reported in Section 3.2 revealed that
over 1/3 of all detected duplications is related to this location. Golomingi’s app-
roach classifies those instances as UNRELATED CLASS, therefore not manage-
able through an automatic procedure. SAME EXTERNAL SUPERCLASS and
SIBLING CLASS have similar characteristics, and share the same refactoring
suggestions. Anonymous classes are recurring examples of SAME EXTERNAL
SUPERCLASS instances, since they usually extend class Object.
cohesive units than blocks, featuring higher reusability. As a result, the detection
procedure of DCRA was configured to detect:
– Type-1 (identical code fragments, only white space differences allowed) and
Type-3 clones (code fragments with added, removed or modified statements);
– block-level clones, for their diffusion, and because they include method-level
clones.
The design and implementation efforts were focused on the locations reported
in Table 2. Also Fowler’s suggestions are mainly related to these four locations.
For all other locations, only “Leave unchanged” is suggested.
Listing 1. DCRA toy example: clone pair Listing 2. DCRA toy example: refactor-
public class SuperClass {} ing preview of the clone pair
public class SubCls1
extends SuperClass { public class SuperClass {
public void method () {
int a = 0; public void method () {
int b = 1; int a = 0;
a ++; int b = 1;
b ++; a ++;
System . out . print ( a + b ); b ++;
} System . out . print ( a + b );
} }
public class SubCls2
extends SuperClass { }
public void method () {
int a = 0; public class SubCls1
int b = 1; extends SuperClass {}
a ++;
b ++; public class SubCls2
System . out . print ( a + b ); extends SuperClass {}
}
} .
– variables used in each clone, labelled using their declaration position and
usage;
– length of each clone, cloned lines and different lines (NiCad only reports the
total length of the longest clone);
10 F.A. Fontana et al.
Regarding the first point, the declaration position was classified in the follow-
ing categories: 1) inside the clone, 2) outside the clone but within its container
method, 3) class attribute, 4) inherited attribute; the usage, instead, was clas-
sified using these other categories: 1) used after clone but within its container
method, 2) read within clone, 3) modified within clone. These criteria were taken
from Higo et al. [11], and applied to our location-based classification, obtaining
a more precise characterization of each clone pair.
The Refactoring Advisor uses the Clone Detailer output to choose the possible
refactoring techniques for each clone pair.
We introduce now the “coupled entity” concept: when clones access variables
or attributes from their local scope (e.g., their container class or method), and
the application of a refactoring would move the code in a different scope, the
reference to those variables or attributes may increase the coupling level of the
refactored clone. A coupled entity is any of these variable or attribute references.
They are evaluated differently for each refactoring kind, because each refactoring
applies different transformations to the code. Coupled entities make the applica-
tion of a refactoring more costly, or not possible without changing the visibility
or placement of variables in the system.
The Refactoring Advisor works independently on each clone pair. First, it
selects all refactoring techniques applicable to the clone pair on the base of
its location, granularity, type and coupled entities. Second, it ranks the selected
techniques, relying on a score based on two criteria: i) relative LOC variation, ii)
compliance to OOP (inheritance, polymorphism and encapsulation). The score
is calculated as the average of two weights, one for each criterion, evaluating the
compliance to each principle. In our example, “Pull up method” would modify
the code as shown in Listing 2. We compute the two weights by evaluating the
code after the refactoring w.r.t. the original. In the following, we explain how
the two weights, i.e., LOC variation and OOP compliance are computed.
Equation 1 defines the refactoring evaluation score. The LOC variation is
obtained (Equation 2) as the ratio of LOC before and after the application of
the refactoring, normalized to the [−1, +1] range. OOP compliance (Equation 3)
is calculated as the average of the values assigned to its three principles: encap-
sulation, inheritance, polymorphism; each value is in the [−1, +1] range, and
has been manually determined for each refactoring during the assessment phase
of the DCRA development. Values (−1, 0, +1) correspond respectively to: the
maximum possible deterioration, no variation, the maximum improvement.
A Duplicated Code Refactoring Advisor 11
encapsulation: 0
OOP Compliance: 0.33 inheritance: 1
PUM Evaluation: 0.66 polymorphism: 0
LOC before: 10
LOC Variation: 1
LOC after: 5
encapsulation: 0
OOP Compliance: −0.66 inheritance: −1
LU Evaluation: −0.33 polymorphism: −1
LOC before: 10
LOC Variation: 0
LOC after: 10
LOCV ar + OOP
Evaluation = (1)
2
LOCBef ore
LOCV ar = −1 (2)
LOCAf ter
Encap + Inh + P olym
OOP = (3)
3
In our clone pair example, the values assigned and derived for each variable of
the two refactorings are resumed in Table 4 (every value depends on the ones on
its right). Our approach allows to give different relative weights to the different
criteria used to produce an evaluation, allowing to tune the refactoring selection
towards, e.g., more OOP quality or more LOC saving.
This component summarizes all advices and clone pair details, providing to the
developers the selected sets of refactoring techniques or clone pairs, sorted by
their weight: techniques are sorted by effectiveness, clone pairs by length. Effec-
tiveness is measured by combining the evaluation of each technique with the
length of the clone pair. Grouping by package was considered because it can
help developers to quickly identify the most problematic subsystems. A class
or package is considered refactorable if it contains effective refactorings, and is
considered affected if it participates to clone pairs.
For each clone pair, only the first refactoring (the one with the higher eval-
uation) is considered, and its weight is normalized according to its clone pair
length (the maximum length of the clones in the pair), to make the comparison
of different refactoring applications coherent. For instance, if the first technique
for a 5 lines-long duplication is evaluated as 1, and the first technique for a
20 lines-long duplication is evaluated as 0.5, the second refactoring will better
improve system quality, since the respective weight values would be 5 and 10.
12 F.A. Fontana et al.
The Refactoring Advice Aggregator provides as output the: top N most effec-
tive refactorings; top N most harmful clone pairs; top N most refactorable pack-
ages and classes; top N most affected packages and classes. The value of N is
currently set to 20.
5 Validation
DCRA was tested on four projects of different size belonging to the Qualitas
Corpus [7], reported in Table 51 . The Refactoring Advisor provided advices for
more than 80 % of clone pairs2 . All refactoring suggestions were then assessed
by hand, to verify their usefulness. The results of the assessment are reported
in Table 6 and Table 7 for different locations, since different locations mean
different possible refactoring sets. In the tables, the number of advices is classified
by location, type, and refactoring suggestion. The shown numbers represent the
ratio of accepted advices (accepted/total), e.g., in Table 6, 81 suggestions out of
90 were accepted for clones in the SAME CLASS location, Type-3, and “Extract
method” suggestion.
The criteria producing the advices proved to be mostly effective, since mainly
refactoring-worthy duplications were proposed. The suggested refactorings were
accepted in most cases, in particular for “Extract method”, “Leave unchanged”,
“Replace method with method object”. Actually, we rejected only 8 % of the
whole advices. This led to suitably refactor 66 % of all duplications found in
1
LOC were computed by the tool CLOC 1.56.
2
The other ones are not managed in the current version of DCRA.
A Duplicated Code Refactoring Advisor 13
References
1. Zibran, M.F., Roy, C.K.: The road to software clone management: A survey. Tech-
nical Report 2012–03, The Univ. of Saskatchewan, Dept. CS, February 2012
2. Roy, C.K., Cordy, J.R.: A survey on software clone detection research. Technical
Report 2007–541, Sch. Computing, Queen’s Univ., Kingston, Canada, September
2007
3. Fowler, M.: Refactoring: Improving the Design of Existing Code. Addison-Wesley
Longman Publishing Co. Inc., Boston (1999)
4. Roy, C.K., Cordy, J.R., Koschke, R.: Comparison and evaluation of code clone
detection techniques and tools: A qualitative approach. Science of Computer Pro-
gramming 74(7), 470–495 (2009). Special Issue on ICPC 2008
5. Golomingi Koni-N’Sapu, G.: Supremo – a scenario based approach for refactoring
duplicated code in object oriented systems. Master’s thesis, Inst. of Computer
Science, Faculty of Sciences, Univ. of Bern, June 2001
6. Roy, C., Cordy, J.: NICAD: accurate detection of near-miss intentional clones using
flexible pretty-printing and code normalization. In: Proc. the 16th IEEE Int’l Conf.
Program Comprehension (ICPC 2008), pp. 172–181. IEEE CS, Amsterdam (2008)
7. Tempero, E., Anslow, C., Dietrich, J., Han, T., Li, J., Lumpe, M., Melton, H.,
Noble, J.: The qualitas corpus: a curated collection of java code for empirical
studies. In: Proc. the 17th Asia Pacific Software Eng. Conf., pp. 336–345. IEEE
CS, Sydney, December 2010
8. Rattan, D., Bhatia, R., Singh, M.: Software clone detection: A systematic review.
Information and Software Technology 55(7), 1165–1199 (2013)
9. Giesecke, S.: Clone-based Reengineering für Java auf der Eclipse-Plattform.
Diplomarbeit, Carl von Ossietzky Universität Oldenburg, Dept. für Informatik,
Abteilung Software Eng., Germany (2003)
10. Giesecke, S.: Generic modelling of code clones. In: Koschke, R., Merlo, E.,
Walenstein, A. (eds.) Duplication, Redundancy, and Similarity in Software.
Dagstuhl Seminar Proc., vol. 06301. Int’les Begegnungs- und Forschungszentrum
für Informatik (IBFI), Germany (2007)
11. Higo, Y., Kusumoto, S., Inoue, K.: A metric-based approach to identifying refac-
toring opportunities for merging code clones in a java software system. J. Software
Maintenance and Evolution: Research and Practice 20(6), 435–461 (2008)
12. Arcelli Fontana, F., Zanoni, M., Ranchetti, A., Ranchetti, D.: Software clone detec-
tion and refactoring. ISRN Software Eng. 2013, 8 (2013)
Random documents with unrelated
content Scribd suggests to you:
Sull’angolo sinistro d’Erba Superiore sorgeva un tempo, come del
resto si riscontra in ogni terra di qualche importanza, il castello, ora
convertito alla più felice villeggiatura de’ signori Valaperta, dove più
d’una volta vidi ospite quel valoroso campione dell’arte pittorica
moderna che è Francesco Hayez.
Di sotto al castello si avvalla con grazioso effetto il terreno, epperò
vien detto Pravalle, pel quale un dì precipitavasi il torrente Bocogna,
menando i soliti guasti de’ suoi pari; ma i Valaperta ne rivolsero a
bene le acque, facendole servire ad una filanda o filatoio.
Sul ciglio dell’opposta eminenza, al di là di Pravalle, si pavoneggia la
elegante villeggiatura de’ signori Conti, che divide coi Valaperta i
vantaggi della fortunatissima posizione.
Erba Superiore è occupata per lo più da ville o case da villeggiatura:
il movimento principale è nondimeno in Erba Inferiore. La borgata è
dotata di Pretura, di ufficio telegrafico e di albergo: ha tutte le
botteghe occorrevoli al vitto, come in una città; massime le carni vi
si trovano eccellenti dai villeggianti; al suo caffè, elegantemente
riaddobbato di fresco e famoso pe’ suoi amaretti, sorta di pasticcini
torrefatti e che contendono il primato con quelli di Saronno, nelle ore
pomeridiane d’autunno vi convengono i signori e le eleganti dei
dintorni, sia venendovi a piedi, sia cogli equipaggi, felici del vedersi
gli uni gli altri; perocchè, del resto, la sosta avvenga in una via
ristretta e senza attrattiva di sorta.
Sulla vetta dell’eminenza su cui seggono le sue case, il pittor Rosa,
nel grandioso caseggiato da lui fabbricato e che affitta nelle ferie
autunnali a famiglie per lo più milanesi in distinti e ammobigliati
appartamenti, costruì un teatro, nel quale in quella stagione recita
talvolta qualche drammatica compagnia sviata.
O per la postale, o per sentieri si discende nel sottoposto piano a
Vill’Incino, dove sorge la prepositurale nella cui giurisdizione è Erba.
Scendendo per la prima, al risvolto trovasi la villa già Clerici, ora
Mazzucchetti, che ognun veggendo augura veder tramutato in
albergo, tanto se ne sente il bisogno e propizia ne appaia la
posizione; ed a fianco di essa al principio della via che si interna e
guida a Lezza sorge altra villa de’ signori Brivio ed un filatoio.
Proseguendo invece per la postale, dopo la Clerici, a un centinaio di
passi si è alla suddetta prepositurale. Alquanto più in là è Incino, o
Mercato d’Incino, che, comunque spopolato tutti i dì della settimana
all’infuori del giovedì, in cui v’è l’antichissimo mercato con opportuni
portici e che diè nome al paese, pure ha memoria di fatti storici.
Eravi certo una colonia romana e vi si trovarono sepolcri e ossa
giganti e armature dell’epoca. Chiamavasi allora Liciniforum, ossia
foro o mercato di Licinio, dal nome di qualche pretore o patrono che
vi comandava la stazione militare, o la colonia; onde il conservato
nome di per sè vale a scalzare d’ogni fondamento la pretesa di chi
volle collocare Liciniforum nel luogo del poco discosto Parravicino.
Del tempo romano qui si sterrarono e lessero due lapidi.
La prima:
Herculi
C. Metilius
Secundus
Votum Solvit Libens Merito.
La seconda:
Jovi Optimo Maximo
Cœsia Tullii Filia
Maxima
Sacerdos
Divae Matidiae [40].
Una terza lapide importa poi di qui riferire, come rinvenuta in alcune
escavazioni, perchè forse fa cenno di un ninfeo qui esistito:
Lymphis Viribus Quintus Vibius
Severus votum solvit.
Anche più tardi, nel medio-evo, da Landolfo da Cardano, arcivescovo
di Milano (979-998), venne Incino eretto in capitanato, investendone
della suprema autorità un suo fratello, come aveva egualmente fatto
degli altri due capitanati di Carcano e Pirovano con Missaglia. I
Comaschi e i Torriani, combattendo Ottone Visconti arcivescovo di
Milano e capo di parte nobilesca, lo diroccarono. Su queste terre, in
età più inoltrata, fervendo le lotte guelfe e ghibelline, la fazione
guelfa portò desolazione e morte, soqquadrando ogni avere e
commettendo i più infami assassinî.
Era poi Incino la pieve più vasta ed importante dell’arcivescovato di
Milano, e fino dal 1288 contava sotto la propria giurisdizione
sessanta chiese. Alla sua prepositurale andava inoltre aggiunta una
collegiata di più canonici, che San Carlo, nel 1584, trasferì alla,
prossima chiesa di Vill’Incino, avendo trovato spopolato il paese.
Quella chiesa antica è per altro degnissima, per la sua vetustà, di
osservazione.
Il giovedì, frequentatissimo è ora il mercato anche da’ villeggianti de’
dintorni; ma verso il meriggio si dirada il concorso, e poco poco il
vecchio mercato di Incino ricade nel primitivo silenzio e nella
solitudine.
Con tutto ciò vi sono due decenti alberghi, dove trovan alloggio
benestanti famiglie sempre nella stagione autunnale, e alle quali
appunto la quotidiana solitudine toglie soggezione e aggiunge quella
maggiore tranquillità che si accorre appunto dalla città a ricercare in
campagna.
ESCURSIONE TRENTESIMASETTIMA.
LA VILLA ADELAIDE.
Da Erba, salendo la via che corre sotto l’antico castello, ora villa
Valaperta, e volgendo a manca, dietro la villa Conti è la strada che
va a Parravicino e subito s’incontra la villa Maria, della contessa
Maria Lurani.
Solo prima dirò una parola di Bucinigo e Pomerio, che si
comprendono nel Pian d’Erba; perocchè dopo segua Villalbese,
celebre per ottime castagne e per freschissimi crotti, a cui gli amatori
del buon vino corrono ad ogni lieta occasione, ma che entra in una
diversa circoscrizione da quella del Pian d’Erba; onde avanti di esso
mi convenga arrestarmi, perchè, tratto dalle bellezze dei luoghi,
facilmente sarei fuorviato dal mio cómpito e arriverei presto per
quella via a Como.
Bucinigo, terricciuola resa vivace da filande e incannatoî, ha più
d’una villa, e fra queste quella de’ signori Vidiserti, che giovami
specialmente ricordare perchè famosa per la sua patriarcale
ospitalità, ivi i moltissimi amici rinvenendo sempre la più graziosa
accoglienza. A noi poco importa di discettare sulla pretesa di coloro
che il nome al paese sia stato lasciato da un buco iniquo, che dicono
esistere tuttavia in un giardino, e così appellato perchè nei tempi
delle prepotenze feudali ivi si desse martirio agli infelici che non
entravan nel genio de’ padroni; o sulla contraria opinione di chi
invece dalla terminazione presume aver il nome radice celtica:
lasciamo ai dotti il trarsi d’impaccio. La torre, di cui son superstiti
pochi ruderi, rammenta le lotte fra loro sostenute dalle famiglie
Sacco e Parravicino.
A Pomerio, vicinissimo, veggonsi avanzi di fortificazioni, che
dovevano esservi necessariamente per rispondere al nome di post
murum, il quale d’altronde era nella terminologia militare d’allora.
A Parravicino, vediamo seguitarsi tre o quattro ville graziose dei
Parravicini, dei Belgiojoso e dei Gariboldi.
Nel giardino de’ Belgiojoso vedesi una torre pendente, come il
campanile di Pisa e la Carisenda di Bologna, ricordata da Dante nel
canto XXXI dell’Inferno.
Segna essa la dimora de’ Parravicini, che, sbandeggiati dai Rusconi
di Como, qui venuti, diedero origine al villaggio.
Di Casiglio non vale far cenno, che per dire essere nella sua chiesa il
sepolcro di Beltramino Parravicino, il qual fu vescovo di Como e poi
di Bologna.
Fuor della strada, è Carcano, che fu già castello forte e sostenne più
assedî, e diè origine alla patrizia famiglia de’ Carcano. In queste
campagne fra Carcano, Orsenigo e Tassera, nel nove agosto 1160 fu
combattuta una fiera battaglia fra gli aderenti di Federico Barbarossa
e quelli de’ Milanesi, e che altri chiamano di Tassera, altri di Carcano,
altri di Orsenigo; ma non importa il nome, mentre giovi invece
conoscere come ne fosse felicissimo risultamento la sconfitta del
Barbarossa e il pieno trionfo de’ Milanesi, determinato
dall’improvviso intervento di quei di Orsenigo ed Erba, ai quali fu in
guiderdone concesso di poi il diritto di cittadinanza. In mezzo a
questi campi, l’arcivescovo Uberto da Pirovano, cantato aveva allora
sul carroccio milanese la messa e tenuta una sacra arringa a’ soldati
onde eccitarli alla pugna contro l’invasore straniero. Nel primo
scontro, che fu terribile, quel sacro carro caduto nelle mani nemiche,
veniva distrutto nel luogo detto il Carudo; ma poi, per l’insperato
soccorso, ristorate d’un tratto le sorti della battaglia, i Milanesi
s’erano presa la rivincita gloriosa.
L’oste nemica si era spinta fino al lago d’Alserio, breve bacino di un
miglio e un quarto di lunghezza e di mezzo di larghezza, sulla cui
sponda è Alserio piccol paese che gli dà il nome. Era nel pantano
delle Lische Amare che vuolsi s’impigliasse il corsiero del Barbarossa,
onde il tempo perduto a districarsene gli avesse a riuscire fatale. —
Castellazzo, paesello, su d’una facile eminenza, fu così detto da un
forte che i Milanesi vi costrussero nel luglio del 1162 per
contrapporre a quello di Carcano, ove si erano rifugiati, pronti a
rinnovare le offese, i fautori dell’Enobarbo.
Al piede di questa bella eminenza evvi un casale ed un’osteria, detta
la Ca’ de’ ladri: è facile indovinare come la brutta denominazione le
venisse dall’essere il luogo isolato e proprio, massime in addietro, a
ricoverarvi siffatta genìa.
Tutti questi paesi or sono animati da ville ed opificî, e nella parte più
elevata di questo punto, vicino al lago, evvi la Retusa, fonte limpida,
salubre e perenne, usufruttata a muovere macine, e ad animare
stabilimenti di serica industria.
Affrettiamoci invece a visitare la villa Adelaide, che sorge a Tassera e
presso alla riva del lago d’Alserio.
Dapprima l’ebbe la famiglia Imbonati, della quale fu ultimo rampollo
quel marchese Carlo, alla cui memoria consacrò Manzoni
splendidissimi versi sciolti, che ora ha il torto di respingere dalle
edizioni fatte sotto gli auspicî suoi; poi l’ereditò il barone Patroni,
che, fattala dall’architetto Clerichetti di Milano ultimare, riducendola
a stile nordico, forse scozzese, diventò fra le più splendide che si
conoscano anche per ricchezza degli interni adornamenti. I giardini
sono egregiamente ordinati; getti d’acque perenni la ravvivano,
comunque non sia tutto ciò giunto, per sentimento degli schifiltosi, a
togliere quell’aria poco allegra che quel seno del lago vi dà. Morto il
Patroni e legata ai Calvi la villa, questi la tennero per poco,
vendendola a un commerciante genovese che volle lucrare
togliendovi molti alberi; ma essa fortunatamente, fin allora chiamata
Patroni, dal suo più generoso proprietario, venne di recente alle mani
del cav. Domenico Basevi, che, profondendovi egregie somme, non
solo la restituì al primitivo splendore, ma ne lo aumentò d’assai.
Figuri quindi il lettore se non avessi allora ragione di dedicarle una
speciale escursione.
Oggi essa ha nuovo battesimo, e dal nome della sposa dell’attuale
proprietario, si intitola Villa Adelaide.
ESCURSIONE TRENTESIMOTTAVA.
MONGUZZO.
Introduzione Pag. 5
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
ebooknice.com