Miroirs/cooperative-software-development
1
0
Fork 0
mirror of https://github.com/amyjko/cooperative-software-development synced 2024-12-25 21:58:15 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Grammar.

Browse source
This commit is contained in:
Andy Ko 2017-06-15 10:54:39 -07:00
parent 4ec6ae9d74
commit b35d50b557
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
architecture.html
View file

@ -44,7 +44,7 @@
<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 computation or state 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 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>