|
|
|
|
| |
| |
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)
|
|
|
| |
|
|
email
us or tel UK: 0161 225 3240 international:
+44 161 225 3240 |
|
|
|
|
