Elaborated on components and connectors.

architecture.html

@@ -45,7 +45,9 @@
 		
 		<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>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 <em>encapsulate</em> some well defined functionality or behavior separate from other functionality and behavior. For example, consider the Java class <em>Math</em>: it encapsulates a wide range of related mathematical functions. This class has an interface that decide how it can communicate with other components (sending arguments to a math function and getting a return value). Components can be more than classes though: they might be a data structure, a set of functions, a library, an API, or even something like a web service. All of these are abstractions that encapsulate interrelated computation and state for some well-define purpose.</p> 
+			
+		<p>The second fundamental unit of architecture is <b>connectors</b>. Connectors are code that transmit information <em>between</em> 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. None of these mechanisms store state or functionality themselves; instead, they are the things that tie components functionality and state together.</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>