<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//TaxonX//DTD Taxonomic Treatment Publishing DTD v0 20100105//EN" "../../nlm/tax-treatment-NS0.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:tp="http://www.plazi.org/taxpub" article-type="research-article" dtd-version="3.0" xml:lang="en">
  <front>
    <journal-meta>
      <journal-id journal-id-type="publisher-id">109</journal-id>
      <journal-id journal-id-type="index">urn:lsid:arphahub.com:pub:3dc5f44e-8666-58db-bc76-a455210e8891</journal-id>
      <journal-title-group>
        <journal-title xml:lang="en">JUCS - Journal of Universal Computer Science</journal-title>
        <abbrev-journal-title xml:lang="en">jucs</abbrev-journal-title>
      </journal-title-group>
      <issn pub-type="ppub">0948-695X</issn>
      <issn pub-type="epub">0948-6968</issn>
      <publisher>
        <publisher-name>Journal of Universal Computer Science</publisher-name>
      </publisher>
    </journal-meta>
    <article-meta>
      <article-id pub-id-type="doi">10.3217/jucs-023-08-0769</article-id>
      <article-id pub-id-type="publisher-id">23438</article-id>
      <article-categories>
        <subj-group subj-group-type="heading">
          <subject>Research Article</subject>
        </subj-group>
        <subj-group subj-group-type="scientific_subject">
          <subject>D.2.2 - Design Tools and Techniques</subject>
          <subject>D.2.7 - Distribution</subject>
          <subject> Maintenance</subject>
          <subject> and Enhancement</subject>
          <subject>D.2.9 - Management</subject>
          <subject>D.2 - SOFTWARE ENGINEERING</subject>
        </subj-group>
      </article-categories>
      <title-group>
        <article-title>Introducing an Architectural Conformance Process in Continuous Integration</article-title>
      </title-group>
      <contrib-group content-type="authors">
        <contrib contrib-type="author" corresp="yes">
          <name name-style="western">
            <surname>Pinto</surname>
            <given-names>Arthur F.</given-names>
          </name>
          <email xlink:type="simple">fparthur@posgrad.ufla.br</email>
          <xref ref-type="aff" rid="A1">1</xref>
        </contrib>
        <contrib contrib-type="author" corresp="no">
          <name name-style="western">
            <surname>Terra</surname>
            <given-names>Ricardo</given-names>
          </name>
          <xref ref-type="aff" rid="A1">1</xref>
        </contrib>
        <contrib contrib-type="author" corresp="no">
          <name name-style="western">
            <surname>Guerra</surname>
            <given-names>Eduardo</given-names>
          </name>
          <xref ref-type="aff" rid="A2">2</xref>
        </contrib>
      </contrib-group>
      <aff id="A1">
        <label>1</label>
        <addr-line content-type="verbatim">Federal University of Lavras, Lavras, Brazil</addr-line>
        <institution>Federal University of Lavras</institution>
        <addr-line content-type="city">Lavras</addr-line>
        <country>Brazil</country>
      </aff>
      <aff id="A2">
        <label>2</label>
        <addr-line content-type="verbatim">Instituto Tecnológico de Aeronáutica, São José dos Campos, Brazil</addr-line>
        <institution>Instituto Tecnológico de Aeronáutica</institution>
        <addr-line content-type="city">São José dos Campos</addr-line>
        <country>Brazil</country>
      </aff>
      <author-notes>
        <fn fn-type="corresp">
          <p>Corresponding author: Arthur F. Pinto (<email xlink:type="simple">fparthur@posgrad.ufla.br</email>).</p>
        </fn>
        <fn fn-type="edited-by">
          <p>Academic editor: </p>
        </fn>
      </author-notes>
      <pub-date pub-type="collection">
        <year>2017</year>
      </pub-date>
      <pub-date pub-type="epub">
        <day>28</day>
        <month>08</month>
        <year>2017</year>
      </pub-date>
      <volume>23</volume>
      <issue>8</issue>
      <fpage>769</fpage>
      <lpage>805</lpage>
      <uri content-type="arpha" xlink:href="http://openbiodiv.net/4935726B-B1BF-53A0-85D6-70B440AD57D7">4935726B-B1BF-53A0-85D6-70B440AD57D7</uri>
      <uri content-type="zenodo_dep_id" xlink:href="https://zenodo.org/record/5505463">5505463</uri>
      <history>
        <date date-type="received">
          <day>28</day>
          <month>06</month>
          <year>2017</year>
        </date>
        <date date-type="accepted">
          <day>27</day>
          <month>08</month>
          <year>2017</year>
        </date>
      </history>
      <permissions>
        <copyright-statement>Arthur F. Pinto, Ricardo Terra, Eduardo Guerra</copyright-statement>
        <license license-type="creative-commons-attribution" xlink:href="" xlink:type="simple">
          <license-p>This article is freely available under the J.UCS Open Content License.</license-p>
        </license>
      </permissions>
      <abstract>
        <label>Abstract</label>
        <p>As software evolves, developers usually introduce deviations from the planned architecture, due to unawareness, conflicting requirements, technical difficulties, deadlines, etc. This occurs in systems with an explicit division of responsibility between groups of classes, such as modules and layers. Although there are architectural conformance tools to identify architectural violations, these tools are underused and detected violations are rarely corrected. To address these shortcomings, this article introduces an architectural conformance process into continuous integration. Thus, the conformance process is triggered by every code integration and, when no violations are detected, the code is integrated into the repository. The implemented tool, called ArchCI, supports the proposed solution using DCL (Dependency Constraint Language) as underlying conformance technique and Jenkins as the Continuous Integration server. We also evaluated the applicability of our proposed solution in a real-world Java project where we incrementally introduced 44 constraints through six releases. As the result, our process was able to detect 42 violations, which have always been fixed before the ensuing release.</p>
      </abstract>
    </article-meta>
  </front>
</article>
