5. Meta-Model (Draft)
When discussing the arc42 template with users (a.k.a. our customers and project partners), we pretty often answer the same question:
What really is a building block?
Let's try a variety of answers - starting top-down with a pretty short version.
Building Blocks in three Seconds
The shortest possible explanation of building blocks:
A building block represent source code.
Building Blocks in 60 Seconds
A somewhat longer explanation of building blocks - which gives you something to thing about (hence 60 seconds):
A building block represents every piece of software which you can either buy, get for free
(e.g. open source) or have to implement yourself.
Now comes your part: Think about the parts of your system, or all the pieces of software that makes up your system. Think about subsystems, layers, packages, libraries and all that stuff. In any reasonably large system there are quite a lot of such pieces - we call those building blocks.
An extensive explanation of building blocks
Building blocks make up the static structure of a software system. They come in different flavours, either blackboxes or whiteboxes. For our purpose of system description we structure building blocks hierarchically - as already shown in chapter 4 of the documentation template of this intro.
On any detail- or abstraction level, your subject-of-interest is a whitebox consisting of a number of blackboxes, but you've already seen that.
How do building blocks and black/whiteboxes relate
to each other: Building blocks are either black- or
whiteboxes, depending on what you (yep, you, dear
reader) and the architect of your system want to
express.
Building blocks are all those things you need to implement your system. See figure 1 for an overview - the explanation follows below.
Figure 1: Metamodel of Building Blocks
Every building block shall have an interface, describing everything the building block needs (input-interfaces) and produces (output-interfaces). Furthermore, as you've already read in the previous parts of this howto, it desperately needs the following information:
- Purpose and responsability
- location: Where can you find the artifacts (documents, source-code, files) for this building block? In simple cases it's just a filename.
- variability: In what respects is this building block variable? Is it useable in other contexts, what kind of flexibility does it provide?
- open issues: Anything not ready yet? Not though about? Risky?
- fulfilled requirements: If you need traceability, here's the place to go...
Kinds of Building Blocks
- Programming constructs, like classes. It should be obvious that such constructs consist of of source code.
- Packages, grouping an arbitrary number of programming constructs. Packages are a kind of namespaces or loose-groupings of building blocks. For example, a layer within your system can be regarded as a package, grouping other building blocks (namely the constituents of this layer).
- Configurations, defining behaviour or interfaces
to existing pieces of software. Examples include
- Springframework configuration files, describing associations between classes which will be instantiated at runtime by the Spring dependency injection engine.
- Hibernate mapping files, describing details of object-relational mapping,
- stylesheet or user-interface-description files (e.g. css, xul, zul), describing layout, color, fonts etc of user interface components
-
Libraries or frameworks, which you can buy, rent or otherwise get from anywhere. Examples:
- user interface frameworks like Apache-Wicket, ZK, Google-Web-Toolkit to support implementation of user interface programming
- persistence and OR-mapping frameworks like Hibernate
- dependency injection frameworks like Spring or Google-Guice
- libraries like PGP (pretty-good-privacy for encryption), ogg-vorbis (mp3 encoding), open-SAML (open-source security-token handling), Mule (open-source enterprise service bus)
Suggestions? We're actively looking for feedback!! Drop us a line :-)