model-based architecture — component architecture basics


component architecture basics



the building language

In some senses, the architecture defines a language in which the variants of the product family may be expressed. For example, if your domain of expertise is hotel billing systems and you have many hotel customers, there will be a lot of parameters and variations between the needs of one client and another. You can invent a set of components that plug together in various ways to meet all their needs; and in a sense, each ocnfiguration is a statement in a language about hotel billing. In fact, you can make this idea quite concrete, by inventing a small language in which to notate the variations in hotel billing, and design a compiler that, given a description in the language, assembles the components in the right way. You could even make it a pictorial language. Workflow systems work this way.

the interface language

A separate language is the one the components use to talk to each other. To make the components able to adopt many configurations (like the ones in the picture below), it's essential to have a common set of interface definitions -- significantly fewer than there are components.

In simple components at the Java Beans level, the language is elementary: this event has happened, this property has been changed. In more complex business components, the language is about events in the domain: Customer X has made an Order for 10 Widgets, etc.

So the interface language definition consists of two parts:

  • the protocol of transactions that components can perform with each other — 'event occurred', 'order cancelled', etc; and the details of the messages used to implement them;
  • the model of what they're talking to each other about — Customers, Orders, etc. (Notice that the important objects here are not the components themselves, but the business concepts they deal with).

In defining the model, it isn't usually sufficient to make a data model: you need to say something about the operations that can be done on the business objects, the sequences of operations that are allowed, and the constraints on values their attributes may take. Different components may have different internal representions of the concepts, so the model should ideally be independent of any implementation — just saying what the effects of operations are, rather than what they achieve.

testing

The architecture should define how components and products will be tested, and provide some quality control support — usually in the form of test harnesses that check conformance to the architecture.

complete solutions for model-based architecture
(consultancy, courses, workshops, mentoring, seminars, development)

what is architecture? | how do you do it? | component architecture | architecture development | case histories
email us  or  telephone   UK: 01625 850 839    International: +44 1625 850 839