Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== Dean, T. R. & Cordy, J. R. A Syntactic Theory of Software Architecture. Transactions on Software Engineering, IEEE CS Press, 1995, 21, 302-313 ======
+===== Abstract =====
+In this paper we introduces a general, extensible diagrammatic syntax for expressing software architectures based on typed nodes and connections and formalized using set theory. The syntax provides a notion of abstraction corresponding to the concept of a subsystem, and exploits this notion in a general mechanism for pattern matching over architectures. We demonstrate these ideas using a small example architecture language with a limited number of types of nodes and connectors, and a small taxonomy of architectures characterized as sets of patterns in the language.
+===== Comments =====
+//Yann-Gaël Guéhéneuc, 2013/09/06//
+The paper introduces the need for a uniform notation to describe software architecture, i.e., the elements and the connections among elements constituting a software system. Such a uniform notation is important to compare and contrast different architectural styles and to identify recurring patterns in architectures, including recurring architectural styles.
+The paper describes a syntactic theory, i.e., the diagrammatic elements needed to syntactically describe some architectures. The theory is based on abstract types, describing the elements of systems, not their semantics/functions. Example of types are Files, Repository, and Tasks. The theory also includes different types of connections, including Streams and Invocations. However, the concrete implementation of the communication protocols used by the connections are not represented. They could be represented through attributes, as suggested in the future work. Probably, it would be interesting nowadays to model communication protocols, given large variety of possibilities: SOAP, simple JSON, RMI, and so on.
+Then, the paper introduces several concepts useful to reason about software architectures:
+    * Partial systems: systems with at least one incomplete connection.
+    * Interface and Abstraction: an interface replaces a partial system into a minimum system, e.g., a single type or connection.
+    * Homogeneous and Heterogeneous Abstractions: an interface whose type is the same or not as the "overall" type of the partial system.
+    * Equivalence: two systems are equivalent iff they have the same interface.
+    * Specialisation: a system is a specialisation of another iff there exists an injection from the elements of the interface of the former into that of the latter.
+Using these concepts, it must be possible to describe most existing software architectures as well as architectural styles. The paper gives many examples of styles, including but not limited to Pipe and Filter, Layered, and Client-Server. Such notation and styles could be used to describe the results of recovery approaches for simultaneous mixed-language systems; possibly with attributes describing the programming languages as well as the communication protocols. Also, using these concepts, the paper introduces pattern matching, first as simple "matching" (partitioning) and then through regular expression, and, finally, through (limited) grammar productions. It also mentions the strength of the matchings as a partial order among the matches. Thanks to pattern matching, it is possible to identify in real architectures some given architectural styles. Nothing is said in the paper on the recovery of the architectures per se.
+The paper mentions several interesting extensions: extending the types, adding semantics to the types and connections, adding attributes to the elements, applying a reasoning framework on the modelled architectures. It also mentions a Prolog-based implementation, which looks very similar to what Wuyts and others have done for design pattern identification.