Architecture, Design, Implementation

Rick Kazman and Ammon H. Eden

This paper presented two axes (intensional/extensional and local/non-local) for differentiating Architecture (non-local intensional), Design (local intensional), and Implementation (local extensional). They also tack on a category “quasi-extensional” for intensional design models that have a bare minimum of implementation already-solved, as in the case of UML diagrams.

I had a few beefs with things they had to say:

First of all, they differentiate intensional vs extensional by noting that intensional specifications use mathematical constraints and thus have an infinite number of possible implementations, whereas extensional specifications are enumerable. However, there are exceptions to both. Mathematical constraints can be finite (e.g. all positive integers less than 10), and so can architectural decisions. The fact that a billing system may accept only an enumerable list of payment types as well as behavior scattered throughout the system dependent upon those types is an indication of architectural decisions (because they are system-wide), even if they are concretely enumerated.

Partly because of the issue of constraints, there seems to be a discrepancy between how generic programming (specifically C++ templating) and UML is handled. On the one side, they argue that UML is not extensional because it is incomplete, but that just sounds like bad or incomplete documentation! Now, UML can be seen as quasi-extensional if only a particular subset is viewed at a time, but then it follows that a C++ templated algorithm or data structure is likewise quasi-extensional until it is likewise placed in the context of its calling implementation. Especially given that UML could be used for code generation (in any programming language that supports the constructs necessary), it seems that the lines can be blurred between an “executable specification” which is not obviously code, and generic code that is not executable without the “details” filled in. In either case, the specification could be executed with the combination of an appropriate interpreter and the “missing details” filled in. Thus, I don’t see a functional difference between generic code fragments (executable if provided with necessary generic specializations), or well-formed grammer specifications such as UML or EBNF (executable if provided with an appropriate interpreter).

Another issue that struck me was that the paper ignores the differences in languages with regard to Design and Implementation. Singleton is one of the more common design patterns referenced, but it is only an artifact of the language. A Python module is always a Singleton. In C++, a template Singleton class may satisfy this role. Infinitely many classes can be converted into singletons in C++ using this implementation… but does that make it no longer a design? The templated class itself is not executable until it is has its template parameters applied, and template specialization allows the parameterized classes to extend themselves, so it seems to fit into the same “quasi-extensional design” role as UML.

Architectural Blueprints – The “4+1” View Model of Software Architecture

Philippe Kruchten

This paper seemed to take the opposite approach to architecture. Instead of a functional view of a software specification, it indicates that much of the architecture is at a level above “non-local intensional” and particularly addressing large software projects. With any large software project, of course there will be issues with hardware limitations (including raw scale, distributability, and concurrency), which are essentially ignored in most lower-level design. However, because of this high-level view, it seems that no effort was made to distinguish between labor expected of top-level architects (i.e. determining top-level processes, tools, and global model design) from labor that could be distributed to module designers; this glosses over the local vs. global classification presented in the other paper, to its detriment.

I don’t quite agree with how they separated design from concurrency. There appeared to be a neglect for how concurrency requirements affect the design (e.g. the Squid proxy server has the nonfunctional requirement for speed under heavy concurrency, which results in a functional specification involving asynchronous programming at a concurrency level that would likely blow the top off of most threading environments). Perhaps because of the age of the paper (and the different perspective), I see more of a continuum particularly between the Process and Physical views, and the effect on concurrency and communicability:

  • Single thread, single process (100% communication, but only one thing at a time, ever)
  • Light-weight threads in a single process (communication and synchronization within a single execution unit without requiring
  • Multiple Processes, single OS (communication through IPC which may require additional protocol development, synchronization requires OS support and becomes more involved, but subsystems can potentially detect and reconver each other)
  • Distributed Processes (commication through networking protocols, synchronization only possible through message-passing, and subsystems cannot handle partial failures themselves)

I realize this is much more detail than the author indented to go into, but I think it illustrates the continuum between processing simplicity and concurrency, and that the Process and Physical views could easily be combined into a single visual model under this continuum.

Overall, I see the distribution of architecture in different documents primarily as a limitation of the design tools (2D diagrams) used. Many “nouns” are common to all of the design “fragments” and can be represented as compositions of of other nouns (zooming), as well as onion-skinning relationships between the nouns within different domains (e.g. object/module dependency graphs, process control or data flows, or other “verbs” applicable between the nouns). I think a more unified approach, where a single set of nouns or atoms is defined along with several classes of relationships, would be more cohesive and easier to navigate than the approach taken here.