testimonials
contact us
about us
partners
site map
courses
clients
home
news
links

 

SOA & UML course in Stockport
(near Manchester)

22nd September 2008


Web Usability Patterns Site


Web Usability Products & Services

A comprehensive tutorial on UML





      
your requirementscustom solutionsexpert helpwhitepapers

  model-based architecture

   
 
   
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:  01625 850 839  international:  +44 1625 850 839