cooperative-software-develo.../architecture.html

<!DOCTYPE html>
<html>
	<head>

		<meta name="viewport" content="width=device-width, initial-scale=1">

		<!-- Latest compiled and minified CSS -->
		<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">

		<!-- Optional theme -->
		<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css" integrity="sha384-rHyoN1iRsVXV4nD0JutlnGaslCJuC7uwjduW9SVrLvRYooPp2bWYgmgJQIXwl/Sp" crossorigin="anonymous">

		<!-- Latest compiled and minified JavaScript -->
		<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>

		<link rel="stylesheet" href="style.css" />

		<title>Architecture</title>

	</head>
	<body>
		<p><a href="index.html">Back to table of contents</a></p>

		<img src="images/church.jpg" class="img-responsive" />
		<small>Credit: Creative Commons 0</small>

		<h1>Architecture</h1>
		<div class="lead">Andrew J. Ko</div>

		<p>Once you have a sense of what your design must do (in the form of requirements or other less formal specifications), the next big problem is one of organization. How will you order all of the different data, algorithms, and control implied by your requirements? With a small program of a few hundred lines, you can get away without much organization, but as programs scale, they quickly become impossible to manage alone, let alone with multiple developers. Much of this challenge occurs because requirements <em>change</em>, and every time they do, code has to change to accommodate. The more code there is and the more entangled it is, the harder it is to change and more likely you are to break things.</p>

		<p>This is where <b>architecture</b> comes in. Architecture is a way of organizing code, just like building architecture is a way of organizing space. The idea of software architecture has at its foundation a principle of <b>information hiding</b>: the less a part of a program knows about other parts of a program, the easier it is to change. The most popular information hiding strategy is <b>encapsulation</b>: this is the idea of designing self-contained abstractions with well-defined interfaces that separate different concerns in a program. Programming languages offer encapsulation support through things like <b>functions</b> and <b>classes</b>, which encapsulate data and functionality together. Another programming language encapsulation method is <b>scoping</b>, which hides variables and other names from other parts of program outside a scope. All of these strategies attempt to encourage developers to maximize information hiding and separation of concerns. If you get your encapsulation right, you should be able to easily make changes to a program's behavior without having to change <em>everything</em> about it's implementation.</p>

		<p>When encapsulation strategies fail, one can end up with what some affectionately call a "ball of mud" architecture or "spaghetti code". A more precise concept is <b>cross-cutting concerns</b>, which are things like features and functionality that span multiple different components of a system, or even an entire system. There is some evidence that cross-cutting concerns can lead to difficulties in program comprehension and long-term design degradation (<a href="#walker">Walker et al. 2012</a>), all of which reduce productivity and increase the risk of defects. As long-lived systems get harder to change, they can take on <em>technical debt</em>, which is the degree to which an implementation is out of sync with a team's understanding of what a product is intended to be. Many developers view such debt as emerging from primarily from poor architectural decisions (<a href="ernst">Ernst et al. 2015</a>). Over time, this debt can further result in organizational challenges (<a href="#khadka">Khadka et al. 2014</a>), making change even more difficult.</p>

		<p>The preventative solution to this problems is to try to design architecture up front, mitigating the various risks that come from cross-cutting concerns (defects, low modifiability, etc.) (<a href="#fairbanks">Fairbanks 2010</a>). A popular method in the 1990's was the <a href="https://en.wikipedia.org/wiki/Unified_Modeling_Language">Unified Modeling Language</a> (UML), which was a series of notations for expressing the architectural design of a system before implementing it. Recent studies show that UML generally not used and generally not universal (<a href="#petre">Petre 2013</a>). More recent developers have investigated ideas of <b>architectural styles</b>, which are patterns of interactions and information exchange between encapsulated components. Some common architectural styles include:</p>

		<ul>
			<li><em>Client/server</em>, in which data is transacted in response to requests. This is the basis of the Internet and cloud computing (<a href="#cito">Cito et la. 2015</a>).</li>
			<li><em>Pipe and filter</em>, in which data is passed from component to component, and transformed and filtered along the way. Command lines, compilers, and machine learned programs are examples of pipe and filter architectures.</li>
			<li><em>Model-view-controller (MVC)</em>, in which data is separated from views of the data and from manipulations of data. Nearly all user interface toolkits use MVC, including popular modern frameworks such as React.</li>
			<li><em>Peer to peer (P2P), in which components transact data through a distributed standard interface. Examples include Bitcoin, Spotify, and Gnutella.</em>
			<li><em>Event-driven</em>, in which some components "broadcast" events and others "subscribe" to notifications of these events. Examples include most model-view-controller-based user interface frameworks, which have models broadest change events to views, so they may update themselves to render new model state.</p>
		</ul>

		<p>Architectural styles come in all shapes and sizes. Some are smaller design patterns of information sharing (<a href="#beck">Beck et al. 2006</a>), whereas others are ubiquitous but specialized patterns such as the architectures required to support undo and cancel in user interfaces (<a href="#bass">Bass et al. 2004</a>).</p>

		<p>One fundamental unit of which an architecture is composed is a <b>component</b>. This is basically a word that refers to any abstraction&mdash;any code, really&mdash;that attempts to encapsulate some well defined functionality or behavior separate from other functionality and behavior. Components have interfaces that decide how it can communicate with other components. It might be a class, a data structure, a set of functions, a library, or even something like a web service. All of these are abstractions that encapsulate interrelated computation and state. The second fundamental unit of architecture is <b>connectors</b>. Connectors are abstractions (code) that transmit information between components. They're brokers that connect components, but do not necessarily have meaningful behaviors or states of their own. Connectors can be things like function calls, web service API calls, events, requests, and so on.</p>

		<p>Even with carefully selected architectures, systems can still be difficult to put together, leading to <b>architectural mismatch</b> (<a href="#garlan">Garlan et al. 1995</a>). When mismatch occurs, connecting two styles can require dramatic amounts of code to connect, imposing significant risk of defects and cost of maintenance. One common example of mismatches occurs with the ubiquitous use of database schemas with client/server web-applications. A single change in a database schema can often result in dramatic changes in an application, as every line of code that uses that part of the scheme either directly or indirectly must be updated (<a href="#qiu">Qiu et al. 2013</a>). This kind of mismatch occurs because the component that manages data (the database) and the component that renders data (the user interface) is highly "coupled" with the database schema: the user interface needs to know <em>a lot</em> about the data, its meaning, and its structure in order to render it meaningfully.</p>

		<p>The most common approach to dealing with both architectural mismatch and the changing of requirements over time is <b>refactoring</b>, which means changing the <em>architecture</em> of an implementation without changing its behavior. Refactoring is something most developers do as part of changing a system (<a href="#murphyhill">Murphy-Hill et al 2009</a>, <a href="#silva">Silva et al. 2016</a>). Refactoring code to eliminate mismatch and technical debt can simplify change in the future, saving time (<a href="#ng">Ng et al. 2006</a>) and prevent future defects (<a href="#kim">Kim et al. 2012</a>).

		<p>Research on the actual activity of software architecture is actually somewhat sparse. One of the more recent syntheses of this work is Petre et al.'s book, <em>Software Design Decoded</em> (<a href="#petre2">Petre et al. 2016</a>), which distills many of the practices and skills of software design into a set of succinct ideas. For example, the book states, "<em>Every design problem has multiple, if not infinite, ways of solving it. Experts strongly prefer simpler solutions over complex ones, for they know that such solutions are easier to understand and change in the future.</em>" These ideas, while powerful in their conciseness, are also grounded in substantial research on how software architects think and work.</p>

		<center class="lead"><a href="specifications.html">Next chapter: Specifications</a></center>

		<h2>Further reading</h2>

		<small>

		<p id="bass">Len Bass, Bonnie E. John. 2003. <a href="http://www.sciencedirect.com/science/article/pii/S0164121202000766" target="_blank">Linking usability to software architecture patterns through general scenarios</a>. Journal of Systems and Software, Volume 66, Issue 3, Pages 187-197.</p>
		<p id="beck">Kent Beck, Ron Crocker, Gerard Meszaros, John Vlissides, James O. Coplien, Lutz Dominick, and Frances Paulisch. 1996. <a href="https://doi.org/10.1109/ICSE.1996.493406" target="_blank">Industrial experience with design patterns</a>. In Proceedings of the 18th international conference on Software engineering (ICSE '96). IEEE Computer Society, Washington, DC, USA, 103-114.</p>
		<p id="cito">J&uumlrgen Cito, Philipp Leitner, Thomas Fritz, and Harald C. Gall. 2015. <a href="https://doi.org/10.1145/2786805.2786826" target="_blank">The making of cloud applications: an empirical study on software development for the cloud</a>. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). ACM, New York, NY, USA, 393-403.</p>
		<p id="ernst">Neil A. Ernst, Stephany Bellomo, Ipek Ozkaya, Robert L. Nord, and Ian Gorton. 2015. <a href="https://doi.org/10.1145/2786805.2786848" target="_blank">Measure it? Manage it? Ignore it? Software practitioners and technical debt</a>. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). ACM, New York, NY, USA, 50-60.</p>
		<p id="fairbanks">Fairbanks, G. (2010). <a href="https://www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104" target="_blank">Just enough software architecture: a risk-driven approach</a>. Marshall & Brainerd.</p>
		<p id="garlan">Garlan, D., Allen, R., & Ockerbloom, J. (1995). <a href="https://doi.org/10.1145/225014.225031" target="_blank">Architectural mismatch or why it's hard to build systems out of existing parts</a>. In Proceedings of the 17th international conference on Software engineering (pp. 179-185).</p>
		<p id="khadka">Ravi Khadka, Belfrit V. Batlajery, Amir M. Saeidi, Slinger Jansen, and Jurriaan Hage. 2014. <a href="http://dx.doi.org/10.1145/2568225.2568318" target="_blank">How do professionals perceive legacy systems and software modernization?</a> In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 36-47.</p>
		<p id="kim">Miryung Kim, Thomas Zimmermann, and Nachiappan Nagappan. 2012. <a href="http://dx.doi.org/10.1145/2393596.2393655" target="_blank">A field study of refactoring challenges and benefits</a>. In Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering (FSE '12). ACM, New York, NY, USA, , Article 50 , 11 pages.</p>
		<p id="murphyhill">Emerson Murphy-Hill, Chris Parnin, and Andrew P. Black. 2009. <a href="http://dx.doi.org/10.1109/ICSE.2009.5070529" target="_blank">How we refactor, and how we know it</a>. In Proceedings of the 31st International Conference on Software Engineering (ICSE '09). IEEE Computer Society, Washington, DC, USA, 287-297.</p>
		<p id="ng">T. H. Ng, S. C. Cheung, W. K. Chan, and Y. T. Yu. 2006. <a href="http://dx.doi.org/10.1145/1181775.1181778" target="_blank">Work experience versus refactoring to design patterns: a controlled experiment</a>. In Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering (SIGSOFT '06/FSE-14). ACM, New York, NY, USA, 12-22.</p>
		<p id="petre">Marian Petre. 2013. <a href="ieeexplore.ieee.org/document/6606618/" target="_blank">UML in practice</a>. In Proceedings of the 2013 International Conference on Software Engineering (ICSE '13). IEEE Press, Piscataway, NJ, USA, 722-731.</p>
		<p id="petre2">Petre, M., van der Hoek, A., & Quach, Y. (2016). <a href="https://books.google.com/books?id=EVE4DQAAQBAJ&lpg=PT17&ots=Tk-8QiRQnP&dq=%22software%20design%20decoded%22&lr&pg=PT17#v=onepage&q&f=false" target="_blank">Software Design Decoded: 66 Ways Experts Think. MIT Press.</p>
		<p id="silva">Danilo Silva, Nikolaos Tsantalis, and Marco Tulio Valente. 2016. <a href="https://doi.org/10.1145/2950290.2950305" target="_blank">Why we refactor? Confessions of GitHub contributors</a>. In Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2016). ACM, New York, NY, USA, 858-870.</p>
		<p id="qiu">Dong Qiu, Bixin Li, and Zhendong Su. 2013. <a href="http://dx.doi.org/10.1145/2491411.2491431" target="_blank">An empirical analysis of the co-evolution of schema and code in database applications</a>. In Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2013). ACM, New York, NY, USA, 125-135.</p>
		<p id="walker">Robert J. Walker, Shreya Rawal, and Jonathan Sillito. 2012. <a href="http://dx.doi.org/10.1145/2393596.2393654" target="_blank">Do crosscutting concerns cause modularity problems?</a> In Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering (FSE '12). ACM, New York, NY, USA, , Article 49 , 11 pages.</p>

		</small>

		<h2>Podcasts</h2>

		<small>

		<p>Software Engineering Daily, <a href="https://softwareengineeringdaily.com/2015/07/27/react-js-with-sebastian-markbage-and-christopher-chedeau/">React JS with Sebastian Marbage and Christopher Chedeua</a></p>

		</small>

	</body>

</html>