Ramblings on Software Architecture: SASSY

Design Patterns

Once the tactics for achieving the desired quality and functionality have been selected the next step is to choose the design patterns that can best implement those tactics. Note that we are not interested in design patterns that deal with algorithms and data structures (such as the observer pattern) but rather we are looking for structural design patterns such as a client-server design.

The SASSY Ontology will need to include a catalogue of architectural design patterns and provide a means to include them into the design for a specific system. High level patterns such as ETL, SOA, Publish/Subscribe, Client/Server, Message Exchange, Peer-to-Pear and Data Warehouse will need to be included. More structural patterns such as Layered Architecture, Pipe and Filter and Event Driven Architecture will also need to be included.

A quick review of the literature has not turned up a very large number of architectural patterns, so this ontology is likely to be easy to implement and manage.

Products

We will also be looking at various existing products that can be used to implement the selected design. For example a message based design might select IBM's Websphere-MQ message queuing product.

Selecting a COTS product may have some side effects. In their book [WAL02] repeatedly stress that the examination of a COTS product may influence the requirements for the project. When users see what a product is capable of, they may want their system to also have that capability. This is to be expected. They also describe cases where the software exhibited behaviour that was not desired because the functionality was not correctly disabled, for example.

The options available will present different flexibility choices. A commercial product will constrain the remainder of the system to its interfaces. An open source product, if used unchanged would be the same, but there is the possibility of making modifications to it. The most flexible alternative is to build your own, but that flexibility comes at the cost of doing the development, and the corresponding time delay. A possible option is to start with COTS, then migrate to OSS or in-house developed at a later release of the system, once the initial time-to-market pressure has eased.

The number of products available is extremely large. While building an ontology of available products would be extremely valuable it will have to be placed beyond the scope of this project for now.