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

Updating link to Bass article (architecture)

Browse source 
updated article link, fix inline link
This commit is contained in:
bxie 2017-04-17 12:13:13 -07:00
parent 5b15ce12a6
commit 778af0bccc
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
architecture.html
View file

@ -44,7 +44,7 @@
<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>Peer to peer (P2P), in which components transact data through a distributed standard interface. Examples include Bitcoin, Spotify, and Gnutella.</em>
</ul> </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>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 computation or state of their own. Connectors can be things like function calls, web service API calls, events, requests, and so on.</p>
@ -58,7 +58,7 @@
<small> <small>
<p id="bass">Len Bass, Bonnie E. John, Natalia Juristo, and Maria-Isabel Sanchez-Segura. 2004. <a href="http://dl.acm.org/citation.cfm?id=999484" target="_blank">Usability-Supporting Architectural Patterns. In Proceedings of the 26th International Conference on Software Engineering (ICSE '04). IEEE Computer Society, Washington, DC, USA, 716-717.</p> <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="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="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="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>