Micro Architecture
Micro ArchitectureArchitecture resolves function and force. Just as it is for Alexander and buildings, so it is for software and any other engineering activity.
MicroArchitecture refers to the elements which express the architecture. On their own they do not satisfy all constraints, but in combination they do.
Often the forces involved are physically motivated, e.g. reliable under failure, therefore the resulting architecture is physically motivated.
12/5 - As seems to be my curse, a term I use gets 'borrowed'. Noticed "J2EE Core Patterns" has a brief reference to Microarchitecture. It'll be interesting to track this.
I've edited the definition to be slightly less obscure.
Definition [use a generous definition of processor :)]: (from The Anatomy of a High Performance Microprocessor A Systems Perspective, by Bruce Shriver and Bennett Smith):
Microarchitecture
Microarchitecture refers to the set of resources and methods used to realize the architecture specification. The term typically includes the way in which these resources are organized as well as the design techniques used in the processor to reach the target cost and performance goals. The microarchitecture essentially forms a specification for the logical implementation.
Forces come from domains/spaces.
Process spaces: memory addresses.
Issues: ObjectIdentity . A proper little essay/chapter thingy. Feedback desired.
Related stuff: ComponentDesignPatterns
Elements so far: BetterQueue, MultiQueue, LockAdapter, PushPullAdapter/PullPushAdapter, AsyncAdapter, ShieldAdapter, TeeAdapter, DualPathAdapter, StateObject (see also ValueObject), DistributedCursor, CompressAdapter/DecompressAdapter.
Larger designs: TreeInSql, DocQueryInSql, PushDocQueryInSql, TimeSeriesInSql
To do list: ThreadableObject, Journal, TransactionManager?, LockManager?, ObjectDock?, ObjectManager?, CommBus?, LoadStub?, StatusMonitor?, OnionSkin?, TransparencyAdapter?, AssociativeDatabase?, CalculationFarm?, MuxAdapter/DemuxAdapter, RetryAdapter?, BootstrapObject?, LeaseAdapter?, GafferQueue?, OutOfBandChannel .
Feedback:
Maybe your book isn't about MicroArchitecture, rather it is about 'adapters'. An adapter is maybe the software equivalent of glue logic on a circuit board - So how about SoftwareGlue as a book title?? -- JamesCrook (you could also talk about facade classes and stuff like that?).
These are very interesting patterns. They are mostly concurrency patterns. Why do you think of them as architectural? Is that because the architect is usually the one who worries about concurrency? These seem to me to be too low-level to be architectural patterns, and you seem to agree because you call them MicroArchitecture. ArchitecturalStyles like PipesAndFilters are what I consider architectural patterns. Something like a PushPullAdapter are common when you are implementing a DataFlow? system that is similar to PipesAndFilters except that the filters don't have their own thread, but instead are more passive streams.
I think we give the word "architecture" different meanings. There IS a growing consensus as to how to define SoftwareArchitecture. "Low level physical issues and their interactions with abstract specification" might fit in to it, but I can't see how. Architecture is usually considered to be high-level, not low-level.
Patterns are usually not generic algorithms, and I don't think your patterns are, either. I think I understand them. That is why I didn't like the name "architectural patterns" for them. -- RalphJohnson
Would it be appropriate to categorize the above "architectural elements" as patterns? I think so. If they'd had CategoryPattern on them, I would have run across these pages much sooner. Also, maybe I'm dense, but I don't understand whether these are supposed to be hardware design elements or software design elements (I think they can function in both realms, and the word "architecture" has so many meanings that won't try to guess which one applies here). -- KrisJohnson
I am reluctant to call them patterns because it may cause confusion with the logically motivated patterns in the GoF book. My elements are physically motivated. My latest analogy for this is one of knots. Design Patterns describes where knots would be used, it is focussed on the intent behind the knotting; I focus on the knots themselves, and let others decide where they might be useful.
They could be hardware elements or software elements, you are correct to see that they may be both.
Architecture is an overused word. My definition is very close to the building/systems definition, and seems to be taking hold, slowly. Even Ralph is starting to agree with me. Give it a year or two :).
Supporting Refs: ThreeTierDistributionArchitecture, MultiTierArchitecture, MessageQueuingArchitectures, SystemsArchitecture, ArchitecturalStyle
From ArchitectureTradeoffAnalysisMethod: QualityAttributes of a large software system reside principally in the system's SoftwareArchitecture.
From QualityAttributes: What does it mean if we say we want a system to be portable or secure? Are things like performance really an entirely different sort of requirement to making the system provide specific business etc related functionality?
From ComponentDefinition: A component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces.
See '4+1 View Of Architecture (Philippe Kruchten)': http://www.rational.com/products/whitepapers/350.jsp.
EditText of this page
(last edited February 27, 2006)
or FindPage with title or text search