1. MORE ON ARCHITECTURES
The main reasons for using an architecture are maintainability and performance.
We want to structure the software into reasonably independent parts for easy maintenance.
We want to be able to increase performance if needed. A suitable architecture allows us to increase processing power where it is needed.
A good architect knows different architectural styles (which are like design patterns) and understands the technology and application to identify the potential performance bottlenecks.
Let’s discuss some models and history…
Software Engineering 2004
Jyrki Nummenmaa

2. Monolithic Architecture / 1
Monolithic systems are not divided into independent parts. They typically run on a single processing unit (computer).
There was a time when computers typically did not talk that much with each other.
This made monolithic systems more or less the only choice.
Lack of complicated communication speeds up processing, but it is hard to improve performance in any other way than increasing processing power for that one computer.
Software Engineering 2004
Jyrki Nummenmaa

3. Monolithic Architecture / 2
Typically and historically, the monolithic system talks with fairly dumb clients (like terminals).
Software Engineering 2004
Jyrki Nummenmaa

4. Client/Server Architecture /1
When terminals were replaced by microcomputers, they started to have processing power.
To use this power just to run a terminal program was a waste of processing capabilities.
Consequently, the microcomputers were used to run a client program, which talked with the mainframe server.
Software Engineering 2004
Jyrki Nummenmaa

5. Client/Server Architecture /2
Fat clients contained more functionalities and data.
Thin clients contained more or less terminal-type functionalities.
Client/Server (C/S) computing was the first step towards multi-tier (multi-layer) architectures on processing unit level.
It allowed a better division of work.
However, fat clients also needed maintenance and installations to keep up with current versions.
Software Engineering 2004
Jyrki Nummenmaa

6. Three-tier architecture / 1
The server side was still monolithic in a basic C/S architecture, which created a performance bottleneck.
As the applications usually had a database, multiplying the database is hard in many cases, which makes it hard to multiply the servers.
However, by having a separate database server it was possible to have multiple application servers.
APPLICATION SERVERS
DATABASE SERVER
Software Engineering 2004
Jyrki Nummenmaa

7. Three-tier architecture / 2
The database server only runs the database, as having several of them is difficult.
If there are database server performance problems, get a more powerful server!
You may use several servers for backup to always have a backup server on-line ready for action.
The three-tier architecture is fairly common.
To make client installation easier, it is possible to have a client server (or UI server), from which the client is software is loaded for execution (like an applet to be executed in the browser).
Software Engineering 2004
Jyrki Nummenmaa

8. Using multiple database servers
If data is replicated to several databases, updating them correctly is a problem – in particular if the replicas must be consistent.
If data is replicated, then it should be easily found somehow. Like assume a library keeps books with title starting with ”A” on one data server, ”B” on a second server, and so on.
Queries based on other selection criteria or data from several servers are problematic. A Z B C
. . .
Software Engineering 2004
Jyrki Nummenmaa

9. Peer-To-Peer Computing
The above processing architectures have assumed that we have separate servers and clients and the configuration of the system is controlled in a centralised fashion.
In Peer-To-Peer computing, each computer (node) is equal, and the nodes may ask each other for processing services.
The nodes may contact each other flexibly and forward processing requests, which removes a fixed configuration for processing.
Grid computing (”a software infrastructure enabling flexible, secure and coordinated resource sharing”)
Software Engineering 2004
Jyrki Nummenmaa

10. Processing Unit vs. Software Architecture
If an architecture divides processing into different types of processing units (clients and various servers), then of course this division implies also a division of the software functionalities.
However, there is also architectural structural decisions, which do not need to be based on the processing unit architecture.
Software Engineering 2004
Jyrki Nummenmaa

11. Dividing the tiers Client tier Application tier
As an example, we may divide the application server functionalities into domain tier and control (application) tier. Typically it is the domain tier, which talks to the database.
It makes a big difference, how the layers talk with each other.
It is typically seen as a good thing, if the layers call each other in top-down fashion and the calls do not pass-by layers (e.g. application layer does not call database layer). - Makes maintenance easier. - Performance may suffer.
Client tier
Application tier
Domain tier
Database tier
Software Engineering 2004
Jyrki Nummenmaa

12. Issues with multi-layer architectures
Number of layers
Error/exception management (what to pass on, what to process)
Callback from lower layers.
Interfaces between layers / encapsulation of layers.
Maintenance knock-on effects (do changes of one layer imply changes in other layers?)
Software Engineering 2004
Jyrki Nummenmaa

13. FRAMEWORKS
A an application framework contains core parts for an application.
The framework serves as a starting-point for application development.
We add new things to the core.
In case of OO software development, a framework may contain a set of core classes.
Naturally, the new system inherits the basic architecture from the framework.
Software Engineering 2004
Jyrki Nummenmaa

14. Black-box vs. white-box frameworks
In black-box frameworks, we just build things on top of the framework without a need to see the implementation details in the framework. - Easy to use
In white-box frameworks, we typically implement new subclasses based on the classes in the framework. - More flexible
Software Engineering 2004
Jyrki Nummenmaa

15. Frameworks vs. components
When you use components, you typically write the “main programs” yourself and call the services from the components.
When you use frameworks, the framework includes the “main programs” and you implement the application-specific special services, which the framework calls. - The so-called Hollywood principle: “Don’t call us, we call you”.
Software Engineering 2004
Jyrki Nummenmaa

16. Frameworks – conclusions
It is harder to write a good application framework than it is to write a good application.
However, if it succeeds, a lot of effort can be saved in producing future applications based on the framework.
In particular, it is possible to get the products out earlier (a time-to-market improvement).
Software Engineering 2004
Jyrki Nummenmaa